Test con screen reader ogni settimana

Un test con screen reader è una sessione breve e ripetuta: venti minuti a settimana su tre flussi, con un lettore e un browser fissi. Serve perché gli strumenti automatici leggono il DOM, non l'annuncio: il criterio 4.1.2 Name, Role, Value, livello A, si verifica ascoltando nome, ruolo e stato di ogni controllo.

La routine

• Landmark e titoli: apri la lista dei landmark, poi quella dei titoli. Ogni pagina deve avere un main e una gerarchia senza salti.
• Tab e focus: attraversa la pagina con Tab e ascolta il nome di ogni controllo; il focus deve restare visibile.
• Un errore di form: invia un form vuoto, ascolta il messaggio e torna sul campo con Shift+Tab.
• Un aggiornamento dinamico: cerca qualcosa e verifica che il risultato sia annunciato senza spostare il focus.

Quale coppia scegliere

Una sola coppia, sempre la stessa, perché il confronto settimanale ha senso solo se lo strumento non cambia. Su Windows: NVDA, licenza GPL-2.0, con Firefox o Chrome. Su macOS e iOS: VoiceOver, incluso nel sistema. Su Linux: Orca, licenza LGPL-2.1. Il criterio 1.3.1 Info and Relationships, livello A, si vede meglio nella lista dei titoli: se la gerarchia visiva non corrisponde a quella del markup, l'elenco la tradisce.

Cosa scrivere nel report

Tre righe per problema: cosa hai sentito, cosa ti aspettavi, quale criterio è coinvolto. «Il bottone dice solo Cerca, non dice in quale sezione» è un difetto di nome accessibile e riguarda 4.1.2. «Dopo l'invio non sento nulla» riguarda 3.3.1 Error Identification, livello A. La data e la versione del lettore rendono il report riproducibile.

Il controllo automatico che lo precede

Prima della sessione, lancia il controllo statico sulle route principali. Costa un minuto e libera i venti minuti per ciò che nessuno strumento sente.

for u in / /pricing /blog; do
  npx --yes pa11y "https://example.com$u" --standard WCAG2AA
done

Pa11y è open source con licenza LGPL-3.0. Riporta selettore e criterio per ogni violazione, e serve a non sprecare l'ascolto su un campo senza etichetta che avresti trovato in automatico.

Il catalogo EneUI

EneUI indicizza la categoria accessibilità, gli stati e il record sonner di shadcn, licenza MIT del progetto shadcn/ui: è il caso in cui l'annuncio di un toast dipende dalla live region, quindi va ascoltato e non solo guardato. Controllo del 1 novembre 2026 sul catalogo da 111.985 componenti.

La limitazione

Una persona con un lettore di schermo non rappresenta tutte le disabilità, e una coppia browser-lettore non copre le altre. Il test settimanale è un filtro, non una certificazione: non sostituisce un audit WCAG completo né il test con utenti disabili reali.

Dove continuare

Il metodo completo è in come fare un audit di accessibilità; la checklist è in componenti React accessibili. Il confronto tra primitive headless è in Radix, Base UI e React Aria.