Un modulo è un elemento che consente a un utente di fornire dati in un campo o in un gruppo di campi. I moduli possono essere semplici come un singolo campo o complicati come un elemento di un modulo a più passaggi con più campi per pagina, convalida dell'input e talvolta un CAPTCHA.
I moduli sono considerati uno degli elementi più difficili da realizzare correttamente dal punto di vista dell'accessibilità, in quanto richiedono la conoscenza di tutti gli elementi che abbiamo già trattato, nonché di regole aggiuntive specifiche solo per i moduli. Con un po' di impegno e tempo, puoi creare un modulo accessibile adatto a te e ai tuoi utenti.
Moduli è l'ultimo modulo specifico per i componenti di questo corso. Questo modulo si concentrerà sulle linee guida specifiche per i moduli, ma tutte le altre linee guida che hai appreso nei moduli precedenti, come la struttura dei contenuti, lo spostamento con la tastiera e il contrasto di colore, si applicano anche agli elementi dei moduli.
Campi
La struttura portante dei moduli sono i campi. I campi sono piccoli pattern interattivi, ad esempio un elemento di input o un pulsante di opzione, che consentono agli utenti di inserire contenuti o fare una scelta. Puoi scegliere tra un'ampia gamma di campi del modulo.
Il consiglio predefinito è di utilizzare pattern HTML consolidati anziché creare qualcosa di personalizzato con ARIA, poiché determinate funzionalità e funzioni, come stati, proprietà e valori dei campi, sono intrinsecamente integrate negli elementi HTML. I campi personalizzati richiedono di aggiungere manualmente la funzionalità ARIA.
Non consigliato: HTML personalizzato con ARIA
<div role="form" id="sundae-order-form">
<!-- form content -->
</div>
Consigliato: HTML standard
<form id="sundae-order-form">
<!-- form content -->
</form>
Oltre a scegliere i pattern dei campi del modulo più accessibili, ove possibile, devi anche aggiungere ai campi gli attributi di completamento automatico HTML. L'aggiunta di attributi di completamento automatico consente una definizione o identificazione più granulare dello scopo per gli user agent e le tecnologie per la disabilità (AT).
Gli attributi di completamento automatico consentono agli utenti di personalizzare le presentazioni visive, ad esempio mostrando un'icona di torta di compleanno in un campo a cui è assegnato l'attributo di completamento automatico per il compleanno (bday). In generale, gli attributi di completamento automatico rendono la compilazione dei moduli più facile e veloce. Questa funzionalità è particolarmente utile per le persone con disturbi cognitivi e di lettura e per chi utilizza le AA, ad esempio gli screen reader.
<form id="sundae-order-form">
<p>Name: <input type="name" autocomplete="name"></p>
<p>Telephone: <input type="tel" autocomplete="tel"></p>
<p>Email address: <input type="email" autocomplete="email"></p>
</form>
Infine, i campi del modulo non devono produrre modifiche contestuali quando ricevono il fuoco o l'input dell'utente, a meno che l'utente non sia stato avvisato del comportamento prima di utilizzare il componente. Ad esempio, un modulo non deve essere inviato automaticamente quando un campo riceve lo stato attivo o quando un utente aggiunge contenuti al campo.
Etichette
Le etichette informano un utente sullo scopo di un campo, se obbligatorio, e possono anche fornire informazioni sui requisiti del campo, ad esempio il formato di immissione. Le etichette devono essere sempre visibili e descrivere con precisione il campo del modulo agli utenti.
Uno dei principi fondamentali dei moduli accessibili è stabilire un collegamento chiaro e preciso tra un campo e la relativa etichetta. Ciò vale sia dal punto di vista visivo sia in termini di programmazione. Senza questo contesto, un utente potrebbe non capire come compilare i campi del modulo.
<form id="sundae-order-form">
<p><label>Name (required): <input type="name" autocomplete="name" required></label></p>
<p><label>Telephone (required): <input type="tel" autocomplete="tel" required></label></p>
<p><label>Email address: <input type="email" autocomplete="email"></label></p>
</form>
Inoltre, i campi del modulo correlati, come un indirizzo postale, devono essere raggruppati in modo programmatico e visivo. Un metodo consiste nell'utilizzare il pattern fieldset e legenda per raggruppare elementi simili.
Descrizioni
Le descrizioni dei campi sono simili alle etichette per scopo in quanto vengono utilizzate per fornire un contesto più ampio al campo e ai requisiti. Le descrizioni dei campi non sono obbligatorie per l'accessibilità se le etichette o le istruzioni del modulo sono sufficientemente descrittive.
Tuttavia, ci sono situazioni in cui è utile aggiungere informazioni aggiuntive per evitare errori nei moduli, ad esempio per indicare la lunghezza minima obbligatoria per un campo della password o per indicare a un utente quale formato di calendario utilizzare (ad esempio MM-GG-AAAA).
Esistono molti metodi diversi per aggiungere descrizioni dei campi ai moduli. Uno dei metodi migliori è aggiungere un attributo aria-describedby all'elemento del modulo, oltre a un elemento <label>. Lo screen reader leggerà sia la descrizione sia l'etichetta.
Se aggiungi l'attributo
aria-labelledby
all'elemento, il valore dell'attributo sostituisce il testo all'interno del
<label>. Come sempre, assicurati di testare il codice finale con tutti gli AT che hai intenzione di supportare.
Errori
Quando crei moduli accessibili, puoi fare molto per impedire agli utenti di commettere errori. All'inizio di questo modulo abbiamo parlato di markup chiaro dei campi, creazione di etichette di identificazione e aggiunta di descrizioni dettagliate, ove possibile. Tuttavia, non importa quanto chiaro ritieni che sia il tuo modulo, alla fine un utente farà un errore.
Quando un utente riscontra un errore nel modulo, il primo passaggio consiste nel comunicarlo. Il campo in cui si è verificato l'errore deve essere identificato chiaramente e l'errore stesso deve essere descritto all'utente in formato di testo.
Esistono diversi metodi per visualizzare i messaggi di errore, ad esempio:
- Un popup in linea vicino al punto in cui si è verificato l'errore
- Una raccolta di errori raggruppati in un messaggio più grande nella parte superiore della pagina
Assicurati di prestare attenzione all'attenzione della tastiera e alle opzioni della regione in tempo reale ARIA quando annunci gli errori.
Se possibile, offri all'utente un suggerimento dettagliato su come correggere l'errore. Esistono due attributi disponibili per notificare agli utenti gli errori.
- Puoi utilizzare l'attributo HTML required. Il browser fornirà un messaggio di errore generico in base ai parametri di convalida specificati.
- In alternativa, puoi utilizzare l'attributo aria-required per condividere un messaggio di errore personalizzato con gli AT. Solo gli AT riceveranno il messaggio, a meno che non aggiungi codice aggiuntivo per renderlo visibile a tutti gli utenti.
Quando un utente ritiene che tutti gli errori siano stati risolti, consentigli di inviare nuovamente il modulo e di fornire un feedback sui risultati dell'invio. Un messaggio di errore indica all'utente che deve apportare altri aggiornamenti, mentre un messaggio di esito positivo conferma che ha risolto tutti gli errori e inviato correttamente il modulo.
Altri criteri di successo
WCAG 2.2 ha introdotto i seguenti criteri di successo incentrati su esperienze con moduli più accessibili:
Verificare di aver compreso
Verifica le tue conoscenze sui moduli accessibili
Quale dei seguenti è l'input del modulo più accessibile?
Email address: <input type="email" required><label>Email address: <input type="email" required></label><label>Email address: <input type="email" required autocomplete="email"></label><label>Email address (required): <input type="email" required aria-describedby="email-validation"> <span id="email-validation" class="validation-message">Please provide a valid email address using the format name@place.com</span></label>