Accessibilità
Come fare un audit di accessibilità
Un audit di accessibilità verifica cosa una persona riesce a fare con tastiera, lettore di schermo e zoom. L'ordine delle prove e ciò che axe non vede.
In sintesi
- Un audit misura compiti completati, non un punteggio automatico.
- L'ordine è tastiera, lettore di schermo, zoom, contrasto, movimento.
- Solo 4 blocchi su 1.556 nel catalogo citano l'accessibilità nei metadati.
Un audit di accessibilità verifica cosa una persona riesce davvero a fare con la tastiera, con un lettore di schermo e con lo zoom al 200%, non il punteggio che compare in un report automatico.
L'ordine delle verifiche
Cinque passaggi, dal più economico al più costoso. Se il primo fallisce, gli altri non servono.
- Tastiera: Tab raggiunge ogni controllo? Il focus è sempre visibile?
- Lettore di schermo: ogni controllo annuncia nome, ruolo e stato?
- Zoom al 200% e al 400%: il testo resta leggibile senza scorrimento orizzontale?
- Contrasto: 4,5:1 sul testo normale, 3:1 sul testo grande e sui bordi dei controlli.
- Movimento: con prefers-reduced-motion attivo l'animazione si ferma?
Il comando
axe-core è il motore di Deque, licenza MPL-2.0, e la sua CLI esegue le regole su una pagina già avviata.
npx @axe-core/cli http://localhost:3000 --exitL'opzione --exit fa fallire la pipeline quando trova una violazione. Il test automatico copre una parte dei criteri; l'ordine qui sopra copre il resto.
Dove il test automatico non arriva
axe trova un'etichetta mancante, non un'etichetta sbagliata. Tre casi che passano il test e bloccano una persona: un ordine di focus che salta il contenuto, un pulsante chiamato «clicca qui», un messaggio di errore che non viene annunciato.
Tre record da guardare
Il navigation menu di shadcn/ui, licenza MIT, la checkbox di Berlix UI e il popover di Efferd mostrano tre contratti diversi; per gli ultimi due la licenza è quella dichiarata dal publisher nel record.
La limitazione
Un audit manuale misura una persona, un browser e un lettore di schermo alla volta. Non esiste un audit che copra tutte le combinazioni: quattro blocchi su 1.556 che citano l'accessibilità dicono quanto il tema sia poco documentato, non quanto il codice sia accessibile.
Dove continuare
La checklist operativa è in componenti React accessibili; l'errore più comune sulle etichette è in aria-label usato male; il confronto tra librerie React misurate è in librerie UI React 2026.
Domande frequenti
Quanto dura un audit di accessibilità?
Da mezza giornata su una pagina a due settimane su un prodotto con più flussi. La durata dipende dal numero di compiti da provare, non dal numero di pagine.
Un test automatico basta per essere conformi?
No. Gli strumenti automatici coprono una parte dei criteri WCAG e non giudicano il senso di un'etichetta. Servono come prima rete, non come prova finale.
Quale livello WCAG devo dichiarare?
AA è il livello richiesto dalla maggior parte delle normative e dei bandi pubblici. AAA resta un obiettivo per parti del prodotto, non per l'intero sito.
Chi deve partecipare a un audit?
Chi scrive il codice, chi progetta i flussi e almeno una persona che usa il prodotto con tecnologia assistiva. Senza quest'ultima, l'audit misura ipotesi.
Come verifico l'accessibilità con la tastiera?
Metti via il mouse e completa il compito principale. Se non ci riesci, il problema è reale e nessun report automatico lo compensa.