# Accessible React components: the 12-point checklist

Twelve checks that separate a component that only looks right from one that works with a keyboard and a screen reader. With states and tests.

> Page: https://ui.eneawork.it/blog/componenti-react-accessibili-checklist
> Markdown: https://ui.eneawork.it/blog/componenti-react-accessibili-checklist.md

*2026-10-31*

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

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

Metti via il mouse. Riesci a completare il flusso principale? Se no, il componente non è accessibile, anche se axe è verde.

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

## FAQ

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