Accessibilità
Componenti React accessibili: la checklist in 12 punti
Dodici controlli che separano un componente “sembra a posto” da un componente usabile con tastiera e screen reader. Con esempi, stati e test rapidi.
In sintesi
- L’accessibilità è un contratto di comportamento, non un attributo aggiunto.
- Focus, nome accessibile e stati sono i tre punti che si rompono per primi.
- Testa da tastiera e a contrasto, non solo con axe.
Un componente React accessibile non è un componente con qualche `aria-*` in più. È un componente che funziona quando il mouse non c’è, quando il contrasto è basso, quando il testo è zoomato e quando lo stato cambia.
La checklist in 12 punti
- 1. Focus visibile: anello da 2–3px, contrasto almeno 3:1.
- 2. Nome accessibile: ogni controllo ha un’etichetta, anche se mostra solo un’icona.
- 3. Ordine di tabulazione: segue l’ordine visivo, senza trappole.
- 4. Tastiera: Enter/Space attivano, Escape chiude, le frecce navigano dove serve.
- 5. Stato: `aria-pressed`, `aria-expanded`, `aria-selected` descrivono il presente.
- 6. Errore: `aria-invalid` e messaggio collegato con `aria-describedby`.
- 7. Live region: i cambiamenti asincroni vengono annunciati senza spam.
- 8. Contrasto: 4.5:1 per il testo, 3:1 per testo grande e bordi di focus.
- 9. Tap target: almeno 44×44px su touch.
- 10. Zoom: il layout regge a 200% senza perdere contenuto.
- 11. Reduced motion: ogni animazione ha un fallback.
- 12. Test reale: tastiera, screen reader e un utente, non solo axe.
I tre errori più comuni
Il primo è usare un `div` cliccabile: perde focus, tastiera e semantica. Il secondo è un’icona senza nome: lo screen reader annuncia “button” e basta. Il terzo è un errore visivo senza annuncio: il messaggio c’è, ma non viene letto.
Dove partire
Parti dai componenti che l’utente usa per completare un’azione: button, input, select, dialog, toast. Le guide Accessible React buttons e Accessible form validation coprono i due punti di ingresso più frequenti.
Domande frequenti
Basta axe per l’accessibilità?
No. Axe trova alcuni errori statici, non prova il flusso da tastiera né la qualità degli annunci.
Devo mettere aria-label su tutto?
No. Un’etichetta visibile è meglio. `aria-label` serve quando il nome accessibile non è nel testo visibile.
Come testo con uno screen reader?
Su macOS VoiceOver, su Windows NVDA o Narrator. Prova il flusso principale, non solo il singolo componente.
Il focus ring è obbligatorio?
Sì, se un controllo è raggiungibile da tastiera. Puoi cambiare lo stile, non eliminarlo senza sostituirlo.
L’accessibilità peggiora il design?
No, lo rende più esplicito. Contrasto, focus e stati leggibili aiutano tutti, non solo chi usa tecnologie assistive.