# Weekly screen reader tests

Twenty minutes a week with NVDA or VoiceOver on three flows catches errors axe cannot see. Criterion 4.1.2 Name, Role, Value is the part you listen to.

> Page: https://ui.eneawork.it/blog/screen-reader-test-quotidiano
> Markdown: https://ui.eneawork.it/blog/screen-reader-test-quotidiano.md

*2026-11-01*

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.

Il catalogo EneUI conta 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, letti da /api/stats il 1 novembre 2026. L'indice dei tag, che copre 1.275 componenti, assegna il tag accessibility a 2 record, aria a 1 e status a 1, letto da /api/components/tags lo stesso giorno.

## La routine

## 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.

## FAQ

### Quanto deve durare il test?

Venti minuti a settimana bastano se i flussi sono tre e la coppia browser-lettore è sempre la stessa. La costanza conta più della durata.

### NVDA o VoiceOver?

Quello che usa il tuo pubblico. NVDA su Windows copre la maggior parte degli utenti desktop; VoiceOver è l'unica scelta su macOS e iOS. Scegline uno e non cambiarlo ogni settimana.

### Posso registrare la sessione?

Sì, meglio se con la voce e i sottotitoli. La registrazione mostra il ritardo dell'annuncio e il punto in cui il focus si perde, due cose che il solo appunto non restituisce.

### Il test automatico non basta?

No. axe e Pa11y trovano ruoli e nomi mancanti, non l'ordine degli annunci né la qualità del testo letto. Il criterio 4.1.2 richiede di ascoltare.

### Come scelgo le tre cose da provare?

Le tre che portano valore: accesso o registrazione, la ricerca, il checkout o l'invio di un form. Sono i flussi in cui un annuncio mancante blocca l'utente.