Perché il tema è il posto giusto per iniziare

Il tema decide la struttura: heading, markup dei menu, contrasto di default, markup dei form. Se la base è solida, plugin e contenuti si innestano su fondamenta accessibili. Se la base è fragile, ogni pagina del sito nasce sbagliata e voi lo scoprite quando il cliente riceve la prima segnalazione — o peggio, quando arriva una causa ADA, negli Stati Uniti una realtà concreta per chi vende lì. Jessica lo dice chiaramente nel podcast: i requisiti delle linee guida WordPress sembrano un muro, ma i frutti più bassi si colgono con sforzo contenuto, sia nei temi classici che nei block theme.

L'argomento economico vale più di quello etico, purtroppo, e lo uso in negoziazione: sistemare l'accessibilità a tema finito costa tre o quattro volte rispetto a farlo nascere accessibile. Retrofit su ventidue template o cura al momento della scrittura: la seconda strada è più corta, sempre.

La checklist che porta all'80%

Questi sono gli otto punti che controllo in ogni audit, in ordine di impatto. Non è una lista simmetrica da manuale: i primi tre coprono la maggior parte dei problemi che incontro davvero.

• Navigazione da tastiera: tab attraverso header, menu, footer. Se il focus scompare o l'ordine è caotico, è la prima cosa da sistemare. Il menu mobile e gli accordion sono i candidati classici.
• Skip to content: un link «salta al contenuto» come primo elemento cliccabile. Mezz'ora di lavoro, beneficio immediato per chi usa lo screen reader su ogni pagina.
• HTML semantico e heading in ordine: un solo H1, H2 e H3 che raccontano la pagina, nav/main/footer come tag e non come div. Il tema li eredita: se li sbaglia, correggere i template.
• Contrasto reale: 4.5:1 per il testo normale, 3:1 per i titoli grandi. I grigi eleganti su bianco sono il vizio più diffuso nei temi premium; misurare, non fidarsi dell'occhio.
• Alt text sulle immagini: il tema deve dare il campo e i contenuti devono riempirlo. Se la media gallery è piena di alt vuoti, parte un lavoro di contenuto a parte.
• Stati di focus visibili: outline personalizzati o di default, mai `outline: none` senza alternativa. Chi naviga da tastiera deve sempre vedere dov'è.
• Form con etichette e messaggi d'errore leggibili: label associati, errori annunciati, niente placeholder usati al posto dell'etichetta. Checkout e form di contatto prima di tutto.
• Aria dove serve, solo dove serve: ARIA corretto sui componenti interattivi custom. ARIA sparso ovunque peggiora le cose: prima il markup nativo, poi ARIA.

Nei block theme una fetta di questo lavoro arriva gratis: il markup dei blocchi core è semantico e testato, e la responsabilità scivola verso chi compone le pagine. È il motivo per cui su progetti nuovi spingo verso i block theme anche per questioni di accessibilità, non solo per il futuro dell'editor.

Il test automatico da 5 minuti

Prima di qualsiasi audit manuale, faccio girare axe-core su tre pagine campione: home, un articolo, una pagina con form. Non sostituisce l'audit umano — becca in genere un terzo dei problemi — ma è gratis e mette in fila le cose evidenti:

# test automatico accessibilità su una pagina live: lista violazioni con gravità
npx @axe-core/cli https://www.mrtux.it/assistenza-wordpress --exit

Poi il test che nessun tool automatico fa per voi: staccate il mouse e navigate la home con la tastiera, finendo fino al footer. Dieci minuti che valgono più di tre report PDF. E chi vuole spingersi oltre trova in questo sito una guida completa sugli audit automatici WCAG con l'AI.

Il caso del tema da 900€, con i numeri

Torniamo all'apertura perché i numeri raccontano meglio della teoria. L'audit del tema premium ha prodotto quattordici problemi: nove risolti in un pomeriggio (focus visibili, skip link, alt mancanti, ordine heading, due contrasti), tre richiesti mezza giornata di sviluppo (menu keyboard-accessible, aria sugli accordion, form di checkout), due erano decisioni di design da negoziare con chi aveva scelto il grigio elegante. Risultato: i percorsi critici — menu, form, checkout — reggono il livello WCAG AA, zero euro di licenze nuove, e i ticket di supporto sono calati da subito perché anche l'usabilità generale ha beneficiato. Il tema non l'ho cambiato: l'ho sistemato. Teme premium e accessibilità non sono nemici, solo richiedono l'audit che il vendor non include.

Block theme o classic: cambia qualcosa per l'accessibilità?

La domanda arriva in ogni audit, e la risposta di Jessica nel podcast coincide con quella che do io: dipende, ma nei block theme una fetta del lavoro arriva gratis. Il markup dei blocchi core — navigazione, immagini, quote — è semantico, testato dalla community e aggiornato con le release. In un classic theme la stessa struttura dipende da come il vendor ha scritto i template PHP, e lì le qualità variano molto di più da tema a tema. In compenso un classic ben fatto con hook e markup pulito resta perfettamente accessibile: non è una guerra di religioni, è una questione di base di partenza. Nei progetti nuovi parto dai block theme proprio per questo, oltre che per la longevità: ereditate markup corretto di default, e i vostri errori si concentrano sui contenuti, non sull'ossatura.

L'eccezione da conoscere è la navigazione: il blocco navigation core è migliorato molto, ma i menu complessi con mega-dropdown restano più semplici da gestire in un classic theme con un JS controllato. Se il vostro progetto ha una navigazione complessa, verificate quel componente per primo, qualunque sia il tipo di tema.

Dove l'AI aiuta davvero (e dove no)

Nell'intervista Jessica nota un punto che condivido: gli agenti AI stanno mettendo l'accessibilità sotto i riflettori, perché la query «controlla l'accessibilità del mio tema» ora produce report concreti in pochi minuti. Li uso nei miei audit come prima passata. Ma il limite rimane: un agente vede il markup, non vede il focus che sparisce a metà animazione, né il contrasto che cambia allo scroll, né l'esperienza di chi naviga con lo screen reader a una mano. Automazione per il volume, umano per il giudizio: è l'unica combinazione che ho visto reggere. Se volete vedere il metodo per esteso, l'audit AI dei template è raccontato passo passo nell'articolo già citato.

Che cosa fare questa settimana

Se gestite un sito per conto di qualcuno — il vostro o di un cliente — la sequenza è questa: test axe sulle tre pagine chiave, navigazione da tastiera completa, correzione dei frutti bassi, audit approfondito solo se emergono problemi strutturali. Chi non ha tempo o team interno può appoggiarsi a chi lo fa per mestiere: il servizio di assistenza WordPress include l'audit periodico e le correzioni, e la routine di manutenzione mensile tiene sotto controllo gli aggiornamenti che altrimenti rompono quanto sistemato. La scusa «il tema è nuovo, sicuramente accessibile» ho smesso di sentirla come risposta: dopo il tema da 900€, verifico sempre.

Riferimenti utili

• WP Tavern #226: Jessica Lyschik, why accessibility in WordPress themes is easier than you think
• Linee guida di accessibilità per i temi su WordPress.org
• Audit accessibilità WordPress con l'AI: WCAG 2026
• Assistenza WordPress: audit e correzioni
• Manutenzione WordPress: la routine mensile

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.

Questo articolo propone un framework a 3 livelli (percepire, descrivere, interagire) per usare l'AI in modo serio sull'accessibilità WordPress, distinguendo ciò che l'AI può fare davvero da ciò che rischia di far peggio. È complementare alla panoramica su WordPress 7.0 per la parte tecnica del core, e al metodo per creare plugin con AI per la parte di sviluppo.

Il problema dell'alt-text automatico: ciò che nessuno dice

L'alt-text (testo alternativo delle immagini) è il punto di partenza dell'accessibilità visiva, e il primo in cui la maggior parte dei team si è cimentata con l'AI. Plugin come AltText.ai, Image SEO, e le funzioni integrate in Jetpack AI e Rank Math Content AI generano descrizioni automatiche per le immagini. Sembra una soluzione perfetta. Non lo è.

Il caso studio: l'allucinazione in un sito di e-commerce

Un negozio online di arredamento ha attivato un plugin AI per generare automaticamente gli alt-text delle immagini dei prodotti. Risultato: per una foto di un divano grigio a tre posti, l'alt-text generato è stato "moderno divano a tre posti in tessuto grigio con cuscini rimovibili". Tecnicamente corretto, ma l'allucinazione è arrivata su un dettaglio: l'AI ha scritto "cuscini rimovibili", che non era una caratteristica verificata del prodotto. Un utente non vedente che avesse fatto affidamento sull'alt-text per decidere l'acquisto avrebbe avuto informazioni errate.

Questo è il cuore del problema: l'AI generativa non distingue tra descrivere ciò che vede e inventare dettagli. Per un'alt-text l'informazione deve essere verificabile, non plausibile.

Cosa dice la WCAG 2.2 sugli alt-text

Le Web Content Accessibility Guidelines 2.2 (raccomandazione W3C, in vigore dal 5 ottobre 2023) sono esplicite. Per il criterio 1.1.1 (Non-text Content):

• L'alt-text deve essere funzionalmente equivalente al contenuto visivo
• Deve servire lo stesso scopo dell'immagine
• Non deve includere informazioni non presenti nell'immagine stessa
• Per immagini decorative, l'alt deve essere vuoto (alt="")
• Per immagini complesse (grafici, diagrammi), serve una descrizione lunga oltre all'alt

Un'alt-text generata da AI che aggiunge dettagli non verificabili viola la WCAG 2.2, anche se "sembra" corretta. Il problema è che il controllo è quasi impossibile da fare in automatico: serve un umano che conosce l'immagine e la confronta con la descrizione.

Il framework a 3 livelli: percepire, descrivere, interagire

L'accessibilità AI-assisted non è un singolo compito, è una pipeline. Ecco un framework operativo che ho usato con diverse agenzie e che si è dimostrato robusto.

Livello 1: PERCEPIRE — rendere il contenuto leggibile dalle tecnologie assistive

Questo è il livello "tecnico" dell'accessibilità: assicurarsi che screen reader, browser con sintesi vocale, e tecnologie assistive possano effettivamente leggere il contenuto della pagina.

L'AI può aiutare in tre modi.

1.1 Generazione di alt-text verificabili.

Non "descrivi l'immagine", ma "elenca solo gli elementi visibili, senza inferire funzioni o dettagli non presenti". Il prompt conta più del modello.

/**
 * Funzione per generare alt-text "sicuro" con un prompt strutturato
 */
function a11y_generate_alt_text( $attachment_id ) {
    $image_url  = wp_get_attachment_url( $attachment_id );
    $alt_manual = get_post_meta( $attachment_id, '_wp_attachment_image_alt', true );

    // Se esiste già un alt-text manuale, non sovrascriverlo
    if ( ! empty( $alt_manual ) ) {
        return $alt_manual;
    }

    $response = wp_ai_request( [
        'connector' => 'openai',
        'model'     => 'gpt-4o-mini',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Sei un assistente specializzato in accessibilità web. '
                           . 'Descrivi SOLO gli elementi visibili nell\'immagine. '
                           . 'Non inferire funzioni, scopi, o dettagli non visibili. '
                           . 'Se l\'immagine è decorativa, rispondi esattamente: DECORATIVE. '
                           . 'Massimo 125 caratteri. Lingua: italiano.',
            ],
            [
                'role'    => 'user',
                'content' => '[Immagine allegata: ' . $image_url . ']',
            ],
        ],
        'max_tokens' => 80,
    ] );

    if ( is_wp_error( $response ) ) {
        return ''; // Fallback: nessun alt, da verificare manualmente
    }

    $alt = trim( $response['choices'][0]['message']['content'] ?? '' );

    // Se l'AI dice "decorativa", l'alt deve essere vuoto
    if ( strtoupper( $alt ) === 'DECORATIVE' ) {
        return '';
    }

    // Salva il draft per review umana (non pubblicare direttamente)
    update_post_meta( $attachment_id, '_a11y_alt_draft', $alt );

    return ''; // Vuoto finché l'umano non approva
}

Nota critica: l'alt-text generato non viene pubblicato direttamente. Va in un draft meta che richiede approvazione umana. È il pattern più sicuro.

1.2 Audit semantico dell'HTML generato.

WordPress 7.0 produce HTML strutturato per i blocchi, ma i page builder (Elementor, Divi, Bricks) e i custom post type possono generare markup non semantico. Un'AI può scansionare il DOM della pagina e segnalare pattern problematici.

/**
 * Aggiunge un check accessibilità al content saving
 */
add_action( 'save_post', function( $post_id ) {
    if ( wp_is_post_revision( $post_id ) ) {
        return;
    }

    $content = get_post_field( 'post_content', $post_id );
    $issues  = [];

    // Check 1: heading hierarchy
    preg_match_all( '/<h([1-6])[^>]*>/i', $content, $headings );
    $levels = array_map( 'intval', $headings[1] ?? [] );
    if ( ! empty( $levels ) ) {
        for ( $i = 1; $i < count( $levels ); $i++ ) {
            if ( $levels[ $i ] - $levels[ $i - 1 ] > 1 ) {
                $issues[] = "Salto di heading: h{$levels[$i-1]} → h{$levels[$i]}";
            }
        }
    }

    // Check 2: link testuali
    if ( preg_match( '/<a[^>]*>\s*(clicca qui|leggi di più|qui)\s*<\/a>/i', $content ) ) {
        $issues[] = 'Link con testo generico ("clicca qui", "leggi di più")';
    }

    // Check 3: tabelle senza th
    if ( preg_match( '/<table[^>]*>(?!.*?<th)/is', $content ) ) {
        $issues[] = 'Tabella senza intestazioni <th>';
    }

    if ( ! empty( $issues ) ) {
        update_post_meta( $post_id, '_a11y_issues', $issues );
    }
} );

1.3 Generazione di transcript automatici per audio/video.

L'AI di speech-to-text (Whisper, AssemblyAI) può generare transcript per podcast e video embed. I transcript devono poi essere corretti da un umano (la precisione di Whisper è 85-95% su italiano, ma basta un errore per颠覆are un significato).

Livello 2: DESCRIVERE — rendere il contenuto comprensibile

Questo è il livello "cognitivo" dell'accessibilità: assicurarsi che il contenuto sia comprensibile da persone con diverse capacità cognitive, linguistiche, e culturali.

2.1 Semplificazione del linguaggio.

L'AI può riscrivere testi complessi in linguaggio semplice, applicando le linee guida Easy-to-Read (ETR) europee o Plain Language americane. Utile per siti della PA, sanità, servizi finanziari.

/**
 * Genera una versione semplificata del post
 */
function a11y_simplify_post( $post_id ) {
    $post = get_post( $post_id );
    if ( ! $post ) {
        return;
    }

    $response = wp_ai_request( [
        'connector' => 'claude',
        'model'     => 'claude-3-5-sonnet',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Riscrivi il seguente testo in italiano semplice (Easy-to-Read). '
                           . 'Frasi brevi (max 15 parole). Parole di uso quotidiano. '
                           . 'Mantieni il significato, non aggiungere informazioni.',
            ],
            [
                'role'    => 'user',
                'content' => wp_strip_all_tags( $post->post_content ),
            ],
        ],
        'max_tokens' => 2000,
    ] );

    if ( is_wp_error( $response ) ) {
        return;
    }

    $simplified = $response['choices'][0]['message']['content'] ?? '';
    update_post_meta( $post_id, '_a11y_simplified', $simplified );
}

2.2 Espansione di acronimi e termini tecnici.

Un altro uso utile: passare il testo all'AI e ottenere un glossario automatico di termini tecnici con definizioni espanse, da linkare o visualizzare in un tooltip.

2.3 Riassunti esecutivi per contenuti lunghi.

Per articoli o documenti di oltre 1.500 parole, un riassunto di 3-5 frasi aiuta utenti con dislessia, ADHD, o barriere cognitive a orientarsi prima di leggere.

Livello 3: INTERAGIRE — rendere il contenuto navigabile

Questo è il livello "interattivo" dell'accessibilità: assicurarsi che le funzionalità della pagina (menu, form, pulsanti) siano usabili da tutti.

3.1 Generazione di label per form fields.

Molti form creati con CF7, WPForms, o Gravity Forms hanno label generiche ("Nome", "Email") quando servirebbero label contestuali ("Nome completo per la fatturazione", "Email aziendale").

/**
 * Analizza i form CF7 e suggerisce label migliori
 */
function a11y_audit_cf7_forms( $form_id ) {
    $form = get_post( $form_id );
    if ( ! $form || 'wpcf7_contact_form' !== $form->post_type ) {
        return [];
    }

    $response = wp_ai_request( [
        'connector' => 'openai',
        'model'     => 'gpt-4o-mini',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Sei un esperto di accessibilità web. Analizza il seguente form WordPress '
                           . 'e suggerisci label più chiare per ciascun campo, seguendo WCAG 2.2 criterio 3.3.2. '
                           . 'Rispondi in JSON con struttura [{"name":"...","label":"...","reason":"..."}].',
            ],
            [
                'role'    => 'user',
                'content' => $form->post_content,
            ],
        ],
        'max_tokens' => 1000,
    ] );

    if ( is_wp_error( $response ) ) {
        return [];
    }

    return json_decode( $response['choices'][0]['message']['content'] ?? '[]', true ) ?: [];
}

3.2 Audit dei contrasti colore.

L'AI può analizzare immagini del sito (via screenshot) e segnalare combinazioni di colori con contrasto insufficiente secondo WCAG 2.2 criterio 1.4.3 (rapporto minimo 4.5:1 per testo normale).

3.3 Generazione di skip-links contestuali.

L'AI può analizzare la struttura della pagina e generare skip-links specifici: "Salta al contenuto principale", "Salta alla ricerca", "Salta al form di contatto". Meglio dei generic skip-link predefiniti.

Audit finale: cosa NON può fare l'AI

L'AI è un assistente, non un auditor. Ci sono cose che richiedono necessariamente l'umano.

Test con screen reader reali

L'AI non può testare l'esperienza utente con NVDA, JAWS, VoiceOver, o TalkBack. Servono sessioni di test con utenti reali o tester esperti. Un'AI può simulare il comportamento di uno screen reader solo in modo approssimativo.

Validazione del focus order

L'ordine del focus da tastiera deve essere logico e prevedibile. L'AI può suggerire un ordine, ma non può testarlo in modo affidabile: serve navigare la pagina con Tab e verificare che il focus si muova in modo sensato.

Valutazione soggettiva dell'esperienza

Cosa si prova a usare il sito con una disabilità? L'AI non ha empatia. Può controllare checklist, non esperienze.

Casi edge con tecnologie assistive specifiche

Switches per paralisi cerebrale, eye-tracking per SLA, screen reader in lingue non supportate bene dall'AI: sono contesti dove l'unica verifica valida è umana.

La checklist operativa del framework

Per implementare il framework a 3 livelli su un sito WordPress in produzione, ecco una checklist concreta.

Fase 1: setup iniziale (1-2 settimane)

• [ ] Audit manuale di accessibilità con axe DevTools o WAVE (rileva il 30-40% dei problemi)
• [ ] Test con screen reader su 5-10 pagine campione
• [ ] Definizione del livello WCAG target (AA è lo standard per la PA, AAA per sanità/scuola)
• [ ] Scelta del provider AI per i task di accessibilità (Claude è particolarmente buono per il reasoning semantico)
• [ ] Policy interna: "tutti i contenuti AI-generated passano per review umana prima della pubblicazione"

Fase 2: implementazione del livello 1 (percepire) — 2-3 settimane

• [ ] Plugin per alt-text AI con flusso di approvazione (vedi codice sopra)
• [ ] Audit semantico HTML al salvataggio dei post (heading hierarchy, link testuali, tabelle)
• [ ] Generazione transcript per audio/video embed
• [ ] Verifica che il theme abbia skip-link e landmark roles corretti

Fase 3: implementazione del livello 2 (descrivere) — 3-4 settimane

• [ ] Versione semplificata (Easy-to-Read) per i contenuti chiave
• [ ] Glossario automatico per termini tecnici
• [ ] Riassunti esecutivi per articoli > 1.500 parole
• [ ] Multi-language con AI per contenuti istituzionali (attenzione: serve review umana per la qualità della traduzione)

Fase 4: implementazione del livello 3 (interagire) — 2-3 settimane

• [ ] Audit form con label contestuali
• [ ] Skip-links dinamici per pagina
• [ ] Validazione contrasti colore
• [ ] Test navigazione da tastiera su tutti i flussi critici (acquisto, registrazione, contatto)

Fase 5: manutenzione continua

• [ ] Audit trimestrale con utenti reali (anche 3-5 utenti con disabilità diverse)
• [ ] Review semestrale dei prompt AI usati (i modelli cambiano, i prompt vanno adattati)
• [ ] Formazione del team editoriale sui principi base di accessibilità
• [ ] Monitoraggio delle segnalazioni utente via form dedicato

Il caso reale: la PA di Bologna

Un esempio concreto di implementazione parziale. Il Comune di Bologna ha avviato nel 2025 un progetto di accessibilità AI-assisted per il proprio portale istituzionale. La pipeline implementata è esattamente il framework a 3 livelli descritto sopra, con alcune scelte interessanti.

• Provider AI principale: Claude (scelto per la qualità del reasoning e per la compliance GDPR)
• Review umana obbligatoria per TUTTI i contenuti AI-generated
• Audit esterno annuale con la Fondazione ASPHI
• Formazione obbligatoria di 8 ore per i redattori

Risultati a 12 mesi: 70% di riduzione delle segnalazioni di inaccessibilità, 40% di riduzione del tempo di produzione dei contenuti semplificati, e un'impressione (soggettiva ma significativa) di maggiore qualità editoriale. Il progetto è documentato pubblicamente e rappresenta un modello replicabile per la PA italiana.

L'errore da non fare: AI al posto dell'umano

L'errore più comune che vedo nelle agenzie è installare un plugin AI per l'accessibilità, far girare la scansione, e dichiarare il sito "accessibile". È sbagliato per tre motivi.

1. L'AI non vede i problemi contestuali. Un link "clicca qui" in un menu di navigazione può essere accettabile, lo stesso link in un footer con 20 link simili è inaccessibile. L'AI non coglie la differenza.
2. L'AI non sa cosa è importante. Un'immagine decorativa con un'alt-text generata viene considerata un successo, ma per un utente con dislessia cognitiva l'alt-text di una decorazione è solo rumore.
3. L'AI non può attestare la conformità. In caso di contenzioso legale, un audit AI non vale come prova di conformità WCAG. Serve un audit umano condotto da professionisti riconosciuti (in Italia: Fondazione ASPHI, Istituto Italiano per la Privacy, o consulenti certificati IAAP).

Domande frequenti

L'AI può davvero migliorare l'accessibilità di un sito WordPress?

Sì, ma come assistente, non come sostituto. L'AI è utile per attività ripetitive (generazione di alt-text, audit semantici, semplificazione del linguaggio) dove un umano deve comunque validare l'output. Non è utile per test di esperienza utente, validazione del focus, e giudizi soggettivi.

Quale provider AI è migliore per l'accessibilità?

Claude (Anthropic) ha dimostrato migliori capacità di seguire prompt strutturati per il reasoning semantico. GPT-4o è equivalente per compiti più semplici. Gemini è indietro di 6-12 mesi su questi task specifici. Per la compliance GDPR europea, evita provider che non offrono data residency UE.

L'alt-text generata da AI è sufficiente per WCAG 2.2 AA?

No. WCAG 2.2 richiede che l'alt-text sia "functionally equivalent" al contenuto visivo, e che sia verificabile. Un'alt-text generata da AI può contenere allucinazioni (informazioni non presenti nell'immagine) che la rendono non conforme. Serve sempre un umano che verifichi.

Esistono plugin WordPress validi per l'accessibilità AI?

Sì, ma con caveat. AltText.ai e Image SEO sono i più usati. ImageSi è una buona alternativa italiana. Tutti vanno configurati con flusso di approvazione umana. Per l'audit complessivo, axe DevTools (estensione browser) e Accessibility Checker (plugin WP) sono i punti di partenza.

L'AI può sostituire un consulente di accessibilità?

No. Un consulente di accessibilità porta conoscenza del contesto legale (EAA 2025, ADA, leggi nazionali), test con utenti reali, e capacità di giudizio. L'AI può essere uno strumento del consulente, non un sostituto.

Come misurare il ROI dell'accessibilità AI?

Tre metriche utili: (1) tempo medio per audit di una pagina (obiettivo: -50% con AI), (2) numero di issue risolte per settimana (obiettivo: +100%), (3) segnalazioni utente per inaccessibilità (obiettivo: -70% in 6 mesi). Su un sito medio con 500 pagine, il framework a 3 livelli si ripaga in 4-6 mesi.

Riferimenti utili per approfondire

• WCAG 2.2 W3C Recommendation - testo integrale delle linee guida.
• WAI-ARIA Authoring Practices - pattern di implementazione per tecnologie assistive.
• European Accessibility Act 2025 - obblighi di legge per siti commerciali in UE dal 28 giugno 2025.
• Equalize Digital - lavoro di Amber Hinds su accessibilità WordPress.
• axe DevTools - estensione browser per audit automatici.
• WAVE Web Accessibility Evaluation Tool - validator online gratuito.
• Screen reader testing guide - tecniche di test con NVDA e VoiceOver.
• Fondazione ASPHI - riferimento italiano per accessibilità digitale.
• Plugin Accessibility Checker - audit automatico su WordPress.
• WordPress nel 2026 mrtux.it - novità del core rilevanti per accessibilità.
• Creare plugin WordPress con AI mrtux.it - per chi vuole sviluppare soluzioni custom di accessibilità.

Questa guida verrà aggiornata quando WCAG 2.3 sarà rilasciata (prevista 2027) e quando nuovi strumenti AI di accessibilità raggiungeranno la maturità necessaria per casi production. Per domande o esperienze sul campo, l'area commenti è aperta.