AI e accessibilità WordPress: framework a 3 livelli per andare oltre l'alt-text automatico

Quando il CEO di Equalize Digital, Amber Hinds, è stata ospite del podcast Press This di Torque Magazine per parlare del rapporto tra AI e accessibilità web, la sua posizione era netta: "L'AI può essere un assistente potente, ma non può sostituire un audit umano di accessibilità. Il rischio più grande è che i team tecnici pensino di aver risolto il problema installando un plugin che genera alt-text automatico, mentre in realtà hanno solo spostato il problema". È un avvertimento che merita di essere preso sul serio, soprattutto in un ecosistema come WordPress dove l'AI è stata integrata a ogni livello: editor, plugin SEO, page builder, generatori di immagini.

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.