# Accessible form errors

An accessible form error reaches three channels: visible text, linked attributes and a screen reader announcement. Miss one and someone is locked out.

> Page: https://ui.eneawork.it/blog/errori-form-accessibili
> Markdown: https://ui.eneawork.it/blog/errori-form-accessibili.md

*2026-11-01*

Un errore di form accessibile arriva su tre canali: testo visibile accanto al campo, attributi collegati al campo e un annuncio per lo screen reader. Se manca un canale, qualcuno resta fuori.

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. La cifra viene da una query all'endpoint, non da una stima: conta i record pubblicati, non la qualità dei componenti.

## Tre canali, non uno

Il testo visibile serve a chi guarda; aria-describedby lega quel testo al campo; aria-invalid dice allo screen reader che il valore non va bene. Un errore segnalato solo con il colore non arriva a chi non distingue rosso e verde.

## Il markup che regge

Email {error && ( {error} )}

Il campo senza errore non ha aria-describedby: l'attributo compare solo quando esiste un messaggio, così lo screen reader non annuncia un id vuoto.

## Le tre regole

## Un controllo da riga di comando

npx @axe-core/cli http://localhost:5173 --exit

axe, distribuito con licenza MPL-2.0, trova gli attributi mancanti ma non giudica se il messaggio si capisce: la prova con lo screen reader resta manuale.

## Record vivi nel catalogo

Tre form da cui partire: login-form, registration-stepper e la categoria blocchi form. Per sfogliare parti da 111.985 componenti.

## La limitazione

Il collegamento funziona solo se l'id esiste nel DOM quando l'errore compare; un annuncio via role="alert" su un nodo già presente non viene letto da tutte le voci. Meglio inserire il nodo con il messaggio, come nello snippet, e verificare su almeno due voci diverse.

## Dove continuare

La checklist completa è in componenti React accessibili; il metodo di verifica è in audit di accessibilità; il confronto misurato fra librerie è in librerie UI React.

## FAQ

### Basta un bordo rosso per segnalare l'errore?

No, il colore da solo non arriva a chi non lo distingue né a uno screen reader. Serve un messaggio scritto e collegato al campo.

### role alert o aria-live?

role alert è una live region educata con priorità alta, quindi va bene per un errore. Su nodi già presenti conviene inserire il nodo insieme al messaggio.

### Dove va il focus dopo un invio fallito?

Sul primo campo non valido, così chi usa la tastiera riparte dal punto giusto senza ricercare l'errore.

### Un test automatico copre l'accessibilità del form?

No, copre gli attributi mancanti. La prova con due screen reader e la tastiera resta necessaria.

### Il messaggio deve stare sopra o sotto il campo?

Sotto il campo, subito dopo, è la posizione abituale. L'importante è che l'ordine di lettura resti campo, poi messaggio.