Accessibilità da tastiera

L’accessibilità da tastiera significa che ogni azione eseguibile da un utente su una pagina può essere eseguita utilizzando solo la tastiera. È il requisito di accessibilità più non negoziabile: senza di essa, nessuna altra tecnologia assistiva funziona.

L’interfaccia da tastiera è l’interfaccia universale

Screen reader, dispositivi switch, controllo vocale, eye-tracking — ogni tecnologia assistiva utilizzata sul web passa in definitiva attraverso il livello della tastiera. Un utente senza alcuna disabilità motoria potrebbe non premere mai Tab, ma lo stesso sito deve essere completamente utilizzabile in questo modo affinché gli utenti con disabilità possano accedervi.

Ecco perché 2.1.1 Tastiera è un criterio di Livello A: non soddisfarlo non rende il sito più difficile, lo rende inutilizzabile per intere popolazioni di utenti.

Cosa richiede concretamente «utilizzabile da tastiera»

• Tab e Shift+Tab spostano il focus in avanti e indietro tra gli elementi interattivi.
• Invio attiva i link e la maggior parte dei pulsanti.
• Spazio attiva i pulsanti e attiva/disattiva le caselle di controllo e i pulsanti radio.
• I tasti freccia navigano all’interno dei widget compositi (tab panel, menu, gruppi radio, listbox, slider).
• Escape chiude le finestre di dialogo modali, i popover e i menu a discesa.
• Pagina su/giù, Inizio/Fine navigano contenuti lunghi dove si applica la convenzione della piattaforma.

Un widget che non implementa il contratto da tastiera che gli utenti di screen reader si aspettano dal proprio ruolo — ad esempio, un ARIA combobox che risponde ai clic ma non ai tasti freccia — è tecnicamente raggiungibile con il focus ma funzionalmente non operativo.

Il metodo di audit manuale più rapido

Si percorra la pagina con Tab dall’inizio assoluto (focus nella barra degli indirizzi, poi Tab) fino al footer. L’ordine di Tab deve corrispondere all’ordine visivo. Ogni elemento cliccabile deve ricevere il focus esattamente una volta. Premere Invio o Spazio su un elemento con focus deve produrre lo stesso risultato del clic. Premere Escape all’interno di un modale deve chiuderlo. Se qualcosa non è raggiungibile, qualcosa viene raggiunto fuori sequenza, o qualcosa intrappola il focus, si sono trovati dei bug.

Cinque minuti di navigazione disciplinata con Tab rilevano più problemi di accessibilità di quindici minuti di scansione con axe-core.

Pattern di errore più comuni

• <div onclick> per card cliccabili. Non raggiungibile con il focus, non attivabile da tastiera, completamente invisibile agli screen reader come elemento interattivo. Occorre usare <button> (per le azioni) o <a href> (per la navigazione).
• Menu a discesa personalizzati che non si aprono con Invio/Spazio. Costruiti con gestori di clic soltanto; gli utenti da tastiera possono portare il focus sul trigger ma non aprire la lista.
• Finestre di dialogo modali che non intrappolano il focus. Tab sposta il focus fuori dal modale e nella pagina (visivamente nascosta) sottostante. Gli utenti non sanno dove si trovano.
• Finestre di dialogo modali che intrappolano il focus eccessivamente. Escape non chiude. L’utente rimane bloccato.
• Destinazione del link di salto non raggiungibile con il focus. Il link di salto punta a #main ma <main id="main"> non ha tabindex="-1", quindi il focus non si sposta davvero e il successivo Tab riparte dall’inizio della pagina.

Due librerie vale la pena conoscere: focus-trap per gestire il focus all’interno dei modali, e tabbable per trovare gli elementi raggiungibili con il focus all’interno di un contenitore. Entrambe sono leggere e non opinionated.