Accessibilità

Il modulo che crei è destinato alle persone. Le persone utilizzano dispositivi diversi. Alcune usano un mouse, altre un dispositivo touch, altre la tastiera altre sono controllate dai movimenti degli occhi. Alcune utilizzano uno screen reader, altre uno schermo piccolo, altre un software per l'ingrandimento del testo. Tutti vogliono utilizzare il tuo modulo. Scopri come rendere il tuo modulo accessibile e utilizzabile per tutti.

Esistono molti controlli modulo tra cui scegliere. Cos'hanno in comune tutti? A ogni controllo del modulo deve essere associato un elemento <label>. L'elemento <label> descrive lo scopo di un controllo modulo. Il testo <label> è visivamente associato al controllo del modulo e viene letto dagli screen reader.

Inoltre, se tocchi o fai clic su <label> viene attivato il controllo del modulo associato, e diventa così un obiettivo più grande.

Utilizza codice HTML significativo per accedere alle funzionalità integrate del browser

In teoria, potresti creare un modulo utilizzando solo elementi <div>. Puoi persino farlo sembrare un <form> nativo. Qual è il problema relativo all'utilizzo elementi non semantici?

Gli elementi del modulo integrati forniscono molte funzionalità integrate. Vediamo un esempio.

Visivamente, <input> (il primo nell'esempio) e <div> hanno lo stesso aspetto. Puoi anche inserire testo per entrambi, poiché <div> ha un contenteditable. Tuttavia, esistono molte differenze tra l'utilizzo di un elemento <input> appropriato e di un <div> simile a un <input>.

Un utente dello screen reader non riconosce <div> come elemento di input, e non riesce a compilare il modulo. L'unica cosa che l'utente dello screen reader sente è "Nome", senza indicare che l'elemento è un controllo modulo per l'aggiunta di testo.

Se fai clic su <div>Name</div>, l'elemento <div> associato a quest'ultimo non viene attivato, mentre <label> e <input> sono collegati tramite gli attributi for e id.

Dopo aver inviato il modulo, i dati inseriti nel <div> non vengono inclusi nella richiesta. Sebbene sia possibile allegare i dati con JavaScript, <input> esegue questa operazione per impostazione predefinita.

Gli elementi integrati del modulo hanno altre funzionalità. Ad esempio, con gli elementi del modulo appropriati e il valore inputmode o type corretto, una tastiera sullo schermo mostra i caratteri appropriati. Utilizzo dell'attributo inputmode su un <div> non può farlo.

Assicurati che gli utenti conoscano il formato dei dati previsto

Puoi definire varie regole di convalida per un controllo modulo. Ad esempio, supponiamo che il campo di un modulo debba contenere sempre almeno otto caratteri. Utilizzi l'attributo minlength, che indica la regola di convalida ai browser. Come puoi assicurarti che gli utenti siano a conoscenza anche della regola di convalida? Dillo a tutti.

Aggiungi informazioni sul formato previsto direttamente sotto il controllo del modulo. Per chiarire per i dispositivi di ausilio, utilizza l'attributo aria-describedby nel controllo del modulo e id nel messaggio di errore con lo stesso valore, per collegare entrambi.

Aiuta gli utenti a trovare il messaggio di errore per un controllo modulo

In un modulo precedente sulla convalida, hai imparato a mostrare i messaggi di errore in caso di dati non validi.

<label for="name">Name</label>
<input type="text" name="name" id="name" required>

Ad esempio, se un campo ha un attributo required e vengono inseriti dati non validi, il browser mostra un messaggio di errore accanto al controllo del modulo quando viene inviato. Anche gli screen reader annunciano il messaggio di errore.

Puoi anche definire un messaggio di errore personalizzato:

Questo esempio richiede ulteriori modifiche per collegare il messaggio di errore al controllo del modulo.

Un approccio semplice consiste nell'utilizzare aria-describedby nel controllo del modulo che corrisponde a id nell'elemento del messaggio di errore. Quindi, utilizza aria-live="assertive" per il messaggio di errore. Le regioni attive di ARIA annunciano un errore agli utenti di screen reader nel momento in cui viene visualizzato.

Il problema di questo approccio per i moduli con più campi è che aria-live di solito annuncerà solo il primo errore nel caso di più errori. Come spiegato in questo articolo relativo a più annunci di aria-live sulla stessa azione, puoi creare un singolo messaggio concatenando tutti gli errori. Un altro approccio è quello di annunciare la presenza di errori, quindi annunciare i singoli errori quando il campo viene selezionato.

Assicurati che gli utenti riconoscano gli errori

A volte i designer colorano di rosso lo stato non valido, utilizzando la pseudo-classe :invalid. Tuttavia, per comunicare un errore o un esito positivo, non dovresti mai fare affidamento solo sul colore. Per le persone daltonismo rosso-verde: i bordi verde e rosso sono quasi identici. Non è possibile vedere se il messaggio è correlato a un errore.

Oltre al colore, utilizza un'icona o aggiungi il tipo di errore al prefisso dei messaggi di errore.

<span class="error">
  <strong>Error:</strong>Please use at least eight characters.
</span>

Aiutare gli utenti a navigare nel modulo

Puoi modificare l'ordine visivo dei controlli del modulo con CSS. Disconnessione tra ordine visivo e navigazione da tastiera (ordine DOM) è problematico per gli utenti di screen reader e tastiere.

Scopri di più su come assicurarti l'ordine visivo della pagina segue l'ordine DOM.

Aiuta gli utenti a identificare il controllo del modulo attualmente selezionato

Usa la tastiera per spostarti questo modulo. Sapevi che lo stile dei controlli del modulo è cambiato una volta che erano attivi? Questo è lo stile dell'elemento attivo predefinito. Puoi sostituirlo con :focus Pseudo-classe CSS. Qualunque sia lo stile che utilizzi in :focus, assicurati sempre che la differenza visiva tra lo stato predefinito e lo stato attivo sia riconoscibile.

Scopri di più su indicatori di attenzione.

Assicurati che il modulo sia utilizzabile

Puoi identificare molti problemi comuni compilando il modulo con dispositivi diversi. Utilizza solo la tastiera e uno screen reader (ad esempio NVDA su Windows o VoiceOver su Mac), o lo zoom della pagina al 200%. Testa sempre i moduli su piattaforme diverse, in particolare i dispositivi o le impostazioni che non usi tutti i giorni. Conosci qualcuno che usa uno screen reader? o qualcuno che utilizza un software per l'ingrandimento del testo? Chiedi loro di compilare il modulo. Le revisioni dell'accessibilità sono ottimi, i test con utenti reali sono ancora migliori.

Scopri di più su come eseguire una revisione dell'accessibilità e come eseguire test con utenti reali.

Risorse