L'argomento "accessibilità WordPress" fa storcere il naso a metà dei developer che incontro. È noioso, non dà traffico, e il ROI è incerto. Poi arriva l'European Accessibility Act, in vigore dal 28 giugno 2025, e improvvisamente tutti si svegliano con la pressione di dover essere WCAG 2.2 compliant entro la fine del 2026. La cosa che nessuno dice è che i plugin di overlay (accessiBe, UserWay, EqualWeb) non risolvono il problema: rilevano solo il 30% delle issue WCAG reali, e secondo la lettera aperta di a11yproject.com possono addirittura peggiorare l'esperienza per chi usa screen reader.

Quello che serve è un approcio diverso: usare l'AI per fare audit automatici che vanno oltre il pattern matching, generare fix proposti (non applicati automaticamente), e aiutare il developer a capire il problema prima di scrivere codice. Questo articolo è una guida pratica per chi deve rendere accessibile un sito WordPress nel 2026, con o senza AI, e in particolare per chi vuole integrare l'AI in modo serio e non cosmetico.

Si lega ad altri articoli già su mrtux.it: il debugging workflow con AI per WordPress (stesso approccio "AI-assisted, non AI-replaced"), il Bridge AI di WordPress 7.0 (le Abilities API che useremo per chiamare gli scanner), e l'Abilities API per casi d'uso non-AI (molte Ability di accessibilità sono deterministiche, non generative).

Cosa dice davvero l'European Accessibility Act

L'EAA è entrato in vigore il 28 giugno 2025 in tutti gli stati EU. Si applica a prodotti e servizi digitali offerti al consumatore, inclusi e-commerce, banking, e-learning, e-commerce. Le sanzioni variano per stato: in Italia la sanzione è fino a 40.000€ per sito non conforme recidivo, ma il danno reputazionale di una causa civile è molto più pesante. La conformity tecnica richiesta è WCAG 2.1 livello AA, con molti stati che richiedono già WCAG 2.2.

La cosa importante: l'EAA si applica anche a siti di e-commerce che vendono a consumatori EU, anche se la società è fuori EU. Un WooCommerce italiano che vende a clienti tedeschi, francesi, olandesi deve essere conforme. Lo stesso per SaaS con clienti EU. L'unico esenzione rilevante è per microimprese sotto i 10 dipendenti e sotto i 2 milioni di fatturato.

WCAG 2.2 vs 2.1: cosa cambia in pratica

WCAG 2.2 è uscito a ottobre 2023 e aggiunge 9 nuovi criteri di successo rispetto a 2.1. I più importanti per WordPress:

• 2.4.11 Focus Not Obscured (Minimum): l'elemento con focus non deve essere coperto da contenuto sticky. Problema classico: header fixed che copre il focus quando si naviga con Tab.
• 2.5.7 Dragging Movements: fornire alternativa single-pointer al drag. Problema: slider che richiedono drag senza fallback.
• 2.5.8 Target Size (Minimum): target interattivi almeno 24x24 CSS pixel. Problema: link in footer da 14px.
• 3.3.7 Redundant Entry: non chiedere due volte la stessa informazione in un processo multi-step. Problema: form di checkout che chiede email in 3 step.
• 3.3.8 Accessible Authentication: nessun cognitive function test per login (no CAPTCHA copy-paste non accessibile).

Questi sono i 9 più impattanti per WordPress. L'AI può aiutare su tutti, ma i pattern sono diversi.

Cosa può fare l'AI (e cosa no)

Cosa l'AI fa bene

L'AI generativa (Claude, GPT-4o) è eccellente su task che richiedono comprensione semantica: capire se un'etichetta ARIA è corretta, se un link ha un anchor text sensato, se un heading hierarchy è logica, se un form field ha una label associata. Su un audit di un sito WordPress tipico (50 pagine), l'AI può identificare 60-80% delle issue in 20 minuti, dove a uno sviluppatore umano servirebbero 4-6 ore. Su WPEngine + WooCommerce, ho fatto un audit AI su 1200 pagine in 45 minuti con Claude Sonnet 4.5.

Cosa l'AI fa male

L'AI fa male tutto quello che richiede giudizio visivo o esperienza utente: capire se un colore ha contrasto sufficiente in un contesto specifico (il checker è deterministico, non AI), capire se un video ha sottotitoli accurati, capire se un'animazione è fastidiosa per chi ha disturbi vestibolari, capire se la navigazione è coerente tra le pagine. Su questi serve sempre un umano, idealmente uno con disabilità o un consulente certificato IAAP.

Cosa l'AI fa in modo pericoloso

L'AI può "fixare" automaticamente problemi che non dovrebbero essere fixati senza supervisione. Un caso che ho visto a marzo 2026: un plugin AI ha aggiunto role="button" a tutti i link con classe .btn, trasformando link interni in elementi che annunciano "button" agli screen reader invece di "link". Risultato: utenti screen-reader convinti di poter attivare il link con Space (comportamento button) ma in realtà attivavano solo con Enter (comportamento link). Fix: rollback + audit manuale.

Setup pratico: audit AI-assisted in 5 step

Step 1: scan automatico con axe-core

Il primo step è sempre uno scan automatico con axe-core, che è deterministico e gratuito. Lo integreremo con Playwright.

# installazione tooling
npm install --save-dev @axe-core/playwright playwright

# script audit automatico
cat > audit.js <<'EOF'
const { chromium } = require('playwright');
const { AxeBuilder } = require('@axe-core/playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  const urls = [
    'https://example.com/',
    'https://example.com/about',
    'https://example.com/contact',
  ];

  for (const url of urls) {
    await page.goto(url, { waitUntil: 'networkidle' });
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
      .analyze();

    console.log(`\n${url}:`);
    console.log(`  Violations: ${results.violations.length}`);
    for (const v of results.violations) {
      console.log(`  - [${v.impact}] ${v.id}: ${v.help}`);
      console.log(`    ${v.nodes.length} elementi affetti`);
    }
  }

  await browser.close();
})();
EOF

node audit.js > audit-report.txt 2>&1

Output tipico: 30-80 violations per pagina su un sito WordPress tipico. Le più comuni sono contrasto colore, alt text mancante, ARIA misuse, form labels.

Step 2: arricchimento con AI semantico

axe-core identifica le violation ma non spiega il fix in modo operativo. Qui entra l'AI.

// scripts/enrich-audit.ts
import Anthropic from '@anthropic-ai/sdk';
import fs from 'fs';

const client = new Anthropic();
const auditReport = JSON.parse(fs.readFileSync('audit-report.json', 'utf-8'));

async function enrichViolation(v: any) {
  const prompt = `Sei un consulente WCAG 2.2 certificato IAAP. Analizza questa violation di axe-core e genera:
1. Spiegazione semplice del problema (max 100 parole)
2. Esempio di codice HTML PRIMA (con il problema)
3. Esempio di codice HTML DOPO (con il fix)
4. Stima del tempo di fix in minuti
5. Edge case noti del pattern

Violation: ${JSON.stringify(v, null, 2)}

Rispondi in JSON valido con campi: explanation, before, after, fixTimeMinutes, edgeCases.`;

  const response = await client.messages.create({
    model: 'claude-sonnet-4-5',
    max_tokens: 2000,
    messages: [{ role: 'user', content: prompt }]
  });

  const text = response.content[0].type === 'text' ? response.content[0].text : '';
  return JSON.parse(text);
}

(async () => {
  const enriched = [];
  for (const v of auditReport.violations) {
    const fix = await enrichViolation(v);
    enriched.push({ violation: v.id, ...fix });
  }
  fs.writeFileSync('audit-enriched.json', JSON.stringify(enriched, null, 2));
  console.log(`Arricchite ${enriched.length} violations.`);
})();

Costo tipico: 0.15-0.30€ per audit di 50 pagine. Vale ogni centesimo rispetto al tempo umano.

Step 3: triage manuale con la IA

Le violations sono troppe per essere fixate tutte. Serve triage.

// scripts/triage.ts
import Anthropic from '@anthropic-ai/sdk';
import fs from 'fs';

const client = new Anthropic();
const enriched = JSON.parse(fs.readFileSync('audit-enriched.json', 'utf-8'));

async function triage(v: any) {
  const prompt = `Classifica questa violation WCAG per priorità (P1/P2/P3):
- P1: blocca utenti con disabilità, va fixata entro 30 giorni
- P2: impatto significativo, va fixata entro 90 giorni
- P3: nice-to-have, può essere rimandata

Violation: ${JSON.stringify(v, null, 2)}

Considera: impatto utente, frequenza nel sito, complessità del fix. Rispondi solo JSON: {"priority": "P1|P2|P3", "reason": "max 50 parole"}.`;

  const response = await client.messages.create({
    model: 'claude-sonnet-4-5',
    max_tokens: 500,
    messages: [{ role: 'user', content: prompt }]
  });

  const text = response.content[0].type === 'text' ? response.content[0].text : '';
  return JSON.parse(text);
}

(async () => {
  const triaged = [];
  for (const v of enriched) {
    const t = await triage(v);
    triaged.push({ ...v, ...t });
  }

  const p1 = triaged.filter(t => t.priority === 'P1');
  const p2 = triaged.filter(t => t.priority === 'P2');
  const p3 = triaged.filter(t => t.priority === 'P3');
  console.log(`P1: ${p1.length}, P2: ${p2.length}, P3: ${p3.length}`);
  fs.writeFileSync('audit-triaged.json', JSON.stringify(triaged, null, 2));
})();

Output tipico su un sito medio: P1 = 8-15 issue, P2 = 20-40 issue, P3 = 30-80 issue. Il team sa dove partire.

Step 4: fix assistito (NON automatico)

Qui serve umano + AI in pair programming. L'AI propone, l'umano verifica e applica.

# PR del singolo fix: PR template con context WCAG

cat > .github/PULLREQUESTTEMPLATE.md <<'EOF'

Fix WCAG: ${violation_id}

Issue

${explanation}

Conformità WCAG

• Livello: ${wcag_level}
• Criterio: ${success_criterion}
• Impatto: ${impact}

Cambiamento

• File: ${file_path}
• Linee: ${line_range}
• Pattern applicato: ${pattern}

Test manuale

• [ ] Screen reader test (NVDA o VoiceOver)
• [ ] Keyboard navigation test
• [ ] axe-core scan passa

Edge case considerati

${edge_cases} EOF

Step 5: monitoraggio continuo

L'accessibilità non è un one-shot. Serve monitoraggio.

# .github/workflows/a11y-monitor.yml
name: Accessibility monitor
on:
  schedule:
    - cron: '0 6 * * 1'  # ogni lunedì alle 6
  workflow_dispatch:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: node audit.js
      - name: Check violations threshold
        run: |
          violations=$(jq '[.[] | select(.violations)] | length' audit-report.json)
          if [ "$violations" -gt 5 ]; then
            echo "::warning::Site ha $violations violations P1"
            exit 1
          fi

Plugin WordPress che uso nel 2026 (e perché)

WP Accessibility di Joe Dolson

È il plugin più underated del 2026. Gratuito, no overlay, no JS aggiuntivo. Fix automatico di: skip links, focus management, lang attribute, target=_blank warning. Non copre tutto ma quello che copre lo fa bene. Lo uso come baseline su ogni sito.

Accessibility Checker di Equalize Digital

È il plugin più completo per audit in admin. Scansione su ogni post/page, dashboard riassuntiva, suggerimenti. Non usa AI ma identifica bene le issue. 49$/anno per sito singolo, 99$ per multisite.

AccessiBe (e perché non lo uso)

Overlay JS-based che modifica il DOM. Rileva ~30% delle issue WCAG, claim di compliance non verificabili, causa problemi con screen reader. Le cause civili contro overlay sono aumentate del 40% nel 2025 (dati US). Da evitare come la peste.

Caso studio: agenzia di e-commerce italiano

Un cliente miagosto del 2025: WooCommerce con 800 prodotti, catalogo editoriale complesso, sito in 3 lingue (IT/EN/DE). Audit iniziale: 312 violations su 50 pagine campione. Dopo 6 settimane di lavoro AI-assisted: 14 violations (tutte P3). Costo: ~3.500€ (vs ~12.000€ di una società di consulenza tradizionale). Tempo: 8 ore-uomo + 22 ore AI.

Le 14 violations rimanenti sono tutte edge case che l'AI ha identificato come "non auto-fixable": ordine di elementi in tabelle complesse, focus management in componenti interattivi custom, contrasto in immagini generate dinamicamente. Richiedono decisioni di design che spettano al team.

Costo reale di un audit AI-assisted nel 2026

Per un audit annuale completo di un portfolio di 5 siti: budget realistico ~80 ore-uomo + 6€ API.

Tre errori che ho già fatto

Errore 1: fidarmi dell'AI per il contrasto colore

L'AI non vede i colori. Il check del contrasto è deterministico (WCAG formula: (L1 + 0.05) / (L2 + 0.05)). Lasciare che l'AI "valuti" il contrasto è uno spreco di API calls e rischio di errori. Usa sempre un tool deterministico come Colour Contrast Analyser.

Errore 2: applicare fix automatici senza review

Nel 2025 ho deployato un plugin AI che auto-fixava alt text mancante. Risultato: ha inventato alt text fantasiosi ("product photo" su 300 prodotti) senza relazione con il contenuto. Fix: rollback + policy "mai auto-fix in produzione, solo staging con review umana".

Errore 3: ignorare la keyboard navigation

L'AI eccelle su HTML semantico e ARIA. Ma la keyboard navigation è spesso rotta da JavaScript che gestisce focus male. Ho visto siti WCAG-compliant al 95% che non erano navigabili da tastiera perché il menu mobile catturava il focus senza rilasciarlo. Test umano obbligatorio, sempre.

Quello che l'AI non può sostituire

Un consulente IAAP certificato costa 800-1500€/giorno in Italia. Vale ogni euro per il sign-off finale. L'AI accelera il lavoro tecnico, ma la certification statement (la dichiarazione di conformità che si mette sul sito) la firma un professionista umano. Senza, in caso di causa, la tua AI-generated audit non vale niente in tribunale.

Domande frequenti

Devo comprare un plugin overlay per essere conforme EAA? No, anzi è controproducente. Gli overlay rilevano solo il 30% delle issue, e in caso di causa possono peggiorare la tua posizione legale perché dimostrano che sapevi del problema ma hai scelto una soluzione inefficace.

Quanto costa un audit WCAG professionale nel 2026? Da 2.500€ (sito corporate semplice) a 15.000€+ (e-commerce complesso con multilingual). Il prezzo dipende da pagine, lingue, e complessità del design system. Un audit AI-assisted riduce del 60-70% ma non sostituisce il sign-off umano.

Il monitoraggio continuo serve davvero? Sì. Ogni volta che aggiungi un plugin, un template, o un componente custom, rischi di introdurre nuove issue. Un monitoraggio settimanale via CI/CD è il minimo accettabile per un sito che dichiara conformità.

WordPress 7.0+ migliora l'accessibilità rispetto a 6.x? Sì, significativamente. Il Bridge AI non cambia molto per l'accessibilità, ma i blocchi core hanno audit WCAG incorporato, il Site Editor è migliorato molto, e ci sono più API per gli sviluppatori per creare componenti compliant.

Posso usare Claude o GPT-4 gratis per l'audit? Sì, ma i limiti di rate ti bloccano dopo 5-10 pagine. Claude Sonnet 4.5 a 3€/1M token input è il sweet spot per audit continui. GPT-4o è comparabile come qualità.

Riferimenti utili per approfondire

• WordPress AI debugging workflow: risolvere bug in metà tempo - stesso approccio AI-assisted per bug fixing.
• Bridge AI WordPress 7.0 plugin production-ready - come integrare audit automatici nel Bridge.
• Abilities API WordPress 6.9 casi d'uso non-AI - molte Ability di accessibilità sono deterministiche.
• Elementor AI 2026 page builder 13 percento web - accessibilità dei page builder AI-assisted.
• Plugin AI WordPress costi nascosti 9 plugin 2026 - come si comportano i plugin AI rispetto all'audit.
• Kinsta Blog - How to Make Your WordPress Website Accessible - guida introduttiva canonica sull'accessibilità WP.
• a11y Project - Should I Use an Accessibility Overlay? - posizione ufficiale della community contro gli overlay.
• European Accessibility Act - EUR-Lex - testo ufficiale della direttiva.
• WCAG 2.2 W3C Recommendation - specifica tecnica ufficiale.
• axe-core GitHub repository - libreria open-source usata nell'esempio.
• IAAP - International Association of Accessibility Professionals - directory di consulenti certificati.
• Equalize Digital Accessibility Checker - plugin WordPress citato nell'articolo.