Cos'è l'accessibilità web? WCAG e design inclusivo spiegati

L'accessibilità web significa costruire siti e app in modo che le persone con disabilità possano usarli — che siano cieche e usino uno screen reader, non possano usare il mouse, abbiano ipovisione o daltonismo, siano sorde, o abbiano disabilità cognitive o di apprendimento. In pratica si riduce a cose come testi alternativi per le immagini, un contrasto di colore sufficiente, moduli con etichette corrette e tutto funzionante con la sola tastiera. Lo standard internazionale è il WCAG, le Web Content Accessibility Guidelines del W3C.

Accessibilità si abbrevia spesso in a11y — «a», poi 11 lettere, poi «y».

Perché l'accessibilità conta quando costruisci con l'AI

I builder AI sono bravi a produrre app che sembrano corrette. L'accessibilità riguarda soprattutto ciò che non si vede in uno screenshot: se un pulsante è davvero un pulsante, se un campo ha un'etichetta che uno screen reader può annunciare, se puoi raggiungere il menu con il tasto Tab.

Per questo conviene chiederla:

• È facile da trascurare. Un menu a discesa stilizzato può sembrare perfetto ed essere impossibile da usare senza mouse. Non te ne accorgi finché non lo verifichi.
• È più economico farla bene subito. Chiedere componenti accessibili fin dal primo prompt costa quasi nulla. Adattare un'app finita significa intervenire su ogni schermata.
• Aiuta tutti. I sottotitoli aiutano chi è in ambienti rumorosi, un buon contrasto aiuta chi usa il telefono alla luce del sole, e le etichette chiare aiutano chiunque a compilare i moduli più in fretta.
• Si sovrappone alla SEO. Titoli corretti, link descrittivi e testi alternativi aiutano anche i motori di ricerca a capire le tue pagine — vedi SEO per siti creati con l'AI.
• Potrebbe essere obbligatoria. A seconda di dove operi e di chi servi, l'accessibilità può essere un obbligo di legge.

Un'analogia quotidiana

Pensa all'ingresso di un edificio.

I gradini vanno bene per molte persone. Una rampa serve alle persone in sedia a rotelle — e anche ai genitori con il passeggino, ai fattorini con il carrello e ai viaggiatori con la valigia. Porte automatiche, segnali chiari, caratteri braille sui pulsanti dell'ascensore e una buona illuminazione eliminano ciascuna una barriera per qualcuno.

L'accessibilità web è la stessa idea per gli spazi digitali: le rampe, i segnali e i corrimano della tua app. E come per un edificio, è molto più facile includere una rampa nei progetti che aggiungerla dopo che il cemento è asciutto.

Il WCAG in breve

Il WCAG è pubblicato dalla Web Accessibility Initiative del W3C. La versione attuale è il WCAG 2.2, pubblicato per la prima volta nell'ottobre 2023. È retrocompatibile: i contenuti conformi al WCAG 2.2 soddisfano anche la 2.1 e la 2.0, e il W3C consiglia di usare l'ultima versione. Il WCAG 2.2 è anche approvato come standard internazionale, ISO/IEC 40500:2025. Un WCAG 3, molto diverso, è in sviluppo come bozza iniziale, non come standard definitivo.

Il WCAG è organizzato in quattro principi, spesso ricordati con la sigla POUR:

Ogni linea guida ha criteri di successo verificabili su tre livelli:

• Livello A — il minimo. Non superare questi criteri blocca completamente alcune persone.
• Livello AA — l'obiettivo standard, e il livello a cui fanno riferimento la maggior parte delle leggi e delle politiche.
• Livello AAA — il livello più alto. Utile da puntare in alcuni punti, ma il W3C non ne raccomanda l'obbligo per interi siti, perché alcuni contenuti non possono soddisfarlo.

Il WCAG 2.2 ha aggiunto nove criteri di successo alla 2.1, tra cui Dimensione del bersaglio (minima) al livello AA — i bersagli cliccabili dovrebbero in genere misurare almeno 24 per 24 pixel CSS, con eccezioni — e Autenticazione accessibile (minima), che limita i passaggi di login basati sulla memoria o su enigmi, come dover riscrivere una password senza poterla incollare. Ha anche eliminato il vecchio criterio «Parsing», ormai obsoleto.

Un esempio concreto: un modulo di registrazione

Ecco un modulo di registrazione che un'AI potrebbe produrre, e ciò che una verifica di accessibilità trova:

Nessuna di queste correzioni cambia molto l'aspetto del modulo. Tutte cambiano se alcune persone riescono a usarlo.

Termini chiave

Idee sbagliate comuni

• «L'accessibilità riguarda solo gli utenti ciechi.» Copre disabilità visive, motorie, uditive, del linguaggio e cognitive, oltre a situazioni temporanee come un braccio rotto.
• «I siti accessibili sono spogli.» L'accessibilità vincola alcune cose — contrasto, stili di focus, dimensione del testo — ma i siti accessibili e belli da vedere sono la norma, non l'eccezione.
• «Un controllo automatico dice 100, quindi abbiamo finito.» Gli strumenti automatici rilevano solo alcuni problemi. Se un testo alternativo è davvero significativo, o se un flusso ha senso con uno screen reader, serve una persona che lo verifichi.
• «Un widget overlay ci rende conformi.» Le barre degli strumenti applicate sopra non possono correggere le etichette mancanti o un accesso da tastiera non funzionante nel tuo codice. Correggi la fonte.
• «Non abbiamo utenti con disabilità.» Potresti semplicemente non saperlo. Molte disabilità non sono visibili, e chi incontra una barriera di solito se ne va e basta.

Cosa chiedere al tuo builder AI

• «Costruisci questo per rispettare il WCAG 2.2 al livello AA.»
• «Usa HTML semantico: pulsanti e link veri, titoli in ordine ed etichette per ogni campo del modulo.»
• «Assicurati che ogni elemento interattivo funzioni con la sola tastiera e abbia uno stile di focus visibile.»
• «Controlla il contrasto di tutti i colori del testo e delle icone — 4,5:1 per il testo normale, 3:1 per il testo grande e le icone.»
• «Aggiungi testi alternativi significativi alle immagini informative e alt vuoti a quelle decorative.»
• «Mostra gli errori dei moduli come testo, collegato al campo, non solo con il colore.»
• «Rispetta l'impostazione di riduzione del movimento dell'utente per le animazioni.»
• «Esegui un controllo automatico di accessibilità ed elenca ciò che non può verificare, così lo controllo a mano.»

Poi verificalo tu: allontana il mouse e prova a completare il flusso principale usando solo Tab, Shift+Tab, Invio e Spazio. Prova lo screen reader integrato del telefono sulla pagina principale. Ingrandisci il browser al 200% e controlla se qualcosa si rompe.

L'accessibilità in Mythex

Mythex non include un verificatore di accessibilità dedicato, quindi tratta l'accessibilità come parte dei tuoi prompt e dei tuoi test. Chiedi il WCAG 2.2 AA fin dal primo prompt, verifica il risultato nell'Anteprima con la tastiera e usa /test per far cliccare all'agente i flussi principali prima di pubblicare — vedi Test dell'app. La ricetta SEO chiede anche titoli semantici e testi alternativi significativi, che servono entrambi gli obiettivi.

Per una checklist pratica, vedi come rendere accessibile il tuo sito. Per il design, leggi come progettare un'app dall'aspetto curato con l'AI, e prima del lancio come testare la tua app prima del lancio. La panoramica WCAG del W3C è la fonte autorevole.

Domande