Identificazione degli errori

Silktide esamina i campi obbligatori dei moduli che sembrano utilizzare una convalida personalizzata invece del controllo integrato del browser e segnala quando non sembra esserci un modo per far arrivare il messaggio di errore alle persone che usano tecnologie assistive.

Perché è importante

Quando un modulo rifiuta una risposta non valida, gli utenti vedenti di solito vedono un contorno rosso o un messaggio vicino al campo. Un utente di non riceve nulla di tutto ciò a meno che la pagina non esponga l'errore nel codice: il modulo si limita a rifiutare l'invio, senza spiegare cosa è andato storto o dove. Il risultato è un modulo che esclude silenziosamente alcuni visitatori.

I browser annunciano automaticamente i propri messaggi di convalida integrati. Il rischio si presenta quando una pagina disattiva questa funzione o la sostituisce con una convalida personalizzata e dimentica di collegare la sostituzione alle .

Come risolvere il problema

Fornisci a ogni campo con convalida personalizzata un percorso programmatico per il relativo messaggio di errore, usando :

<!-- Problema: convalida personalizzata senza un canale di errore accessibile -->
<form novalidate>
  <input type="text" required>
  <span class="error">Inserisci il tuo nome</span>
</form>

<!-- Soluzione: il campo rimanda al proprio messaggio di errore -->
<form novalidate>
  <input type="text" required aria-describedby="name-error">
  <span id="name-error" class="error">Inserisci il tuo nome</span>
</form>

Una qualsiasi delle seguenti opzioni soddisfa il controllo:

aria-errormessage sul campo, che rimanda all'elemento in cui inserisci il testo dell'errore (imposta aria-invalid="true" quando viene mostrato l'errore).
aria-describedby sul campo, che rimanda all'elemento del messaggio.
Una all'interno del modulo: un elemento con role="alert", role="status" o aria-live in cui la convalida inserisce il testo dell'errore.

In alternativa, rimuovi la personalizzazione e lascia che la convalida nativa del browser segnali gli errori, poiché è accessibile per impostazione predefinita.

Come esegue il controllo Silktide

Individua i campi obbligatori visibili: input, aree di testo e menu di selezione contrassegnati con required o aria-required="true".
Mantiene solo i campi per i quali vi sono prove che la convalida nativa del browser viene ignorata o sostituita: il modulo ha novalidate, un controllo di invio ha formnovalidate, il campo è contrassegnato con aria-invalid, utilizza aria-required senza l'attributo nativo required oppure il campo o il modulo contiene indicatori di convalida personalizzata, come attributi relativi agli errori o contenitori di messaggi di errore.
Per ogni campo di questo tipo, cerca un canale di errore accessibile: un riferimento aria-errormessage valido, un riferimento aria-describedby valido o una regione live all'interno del modulo.
Segnala i campi che non ne hanno alcuno. Si tratta di un avviso e non di un errore confermato, perché il comportamento della convalida durante l'esecuzione non può essere osservato completamente dal codice della pagina.

Risoluzione dei problemi

I miei errori vengono annunciati correttamente

Il controllo cerca la struttura che rende possibili gli annunci, non l'annuncio in sé. Se il tuo framework inserisce una regione live o i riferimenti ARIA solo nel momento in cui si verifica un errore, la pagina caricata non mostra alcun canale e il campo viene segnalato. Aggiungere in anticipo l'elemento del messaggio (vuoto) e il relativo riferimento risolve il problema ed è anche più solido.

L'elemento del messaggio a cui si fa riferimento non esiste ancora

I riferimenti devono puntare a elementi presenti nella pagina. Un aria-describedby che punta a un id creato solo in un secondo momento viene considerato privo di canale.