Navigare il web con la tastiera

Un paio di mesi fa ho scritto un post in cui riassumevo i miei sforzi per rendere il menu a tendina qui sopra più accessibile agli utenti che utilizzano la tastiera per navigare tra le pagine del sito. Il lavoro fatto per implementare le linee guida del consorzio W3C mi ha dato lo spunto per il post di oggi: quali altri accorgimenti bisogna mettere in campo affinché un sito (non solo il menu) sia facilmente consultabile usando una tastiera? In un settore in cui la tecnologia è cambiata quasi radicalmente negli ultimi dieci anni (basti pensare a quello che si può fare oggi con il solo CSS, senza dover ricorrere a pezze di vario tipo per implementare sistemi a griglia), leggere le linee guida degli organismi preposti non è più sufficiente: bisogna saper conoscere gli strumenti tecnici per tradurre quelle raccomandazioni in codice.

Come ho sempre sostenuto, bisogna partire dal codice HTML: un uso intelligente dei tag semantici (<header>, <footer>, <section>, giusto per citarne alcuni) è indispensabile per gettare delle fondamenta solide su cui poi costruire tutto il resto, inclusa la navigazione da tastiera assistita da un lettore vocale. Sappiamo tutti che, quando un utente preme il tasto Tab, il successivo elemento attivabile nella pagina viene evidenziato e quando preme i tasti Maiusc + Tab, l’elemento precedente (nella sequenza definita dal codice sorgente) verrà attivato. Quindi la domanda diventa: quali elementi devono poter ricevere il focus? La risposta è abbastanza semplice: tutti quelli che implementano una qualche azione che l’utente può compiere per interagire con il sito. Come ad esempio button, a, input, textarea, ed i pulsanti associati agli elementi audio e video. Una volta focalizzati (lo so che non è ideale, ma focusati non lo userò mai, perdonami), alcuni di essi vanno attivati premendo il tasto Invio o la barra spaziatrice, mentre per altri (come il <select>), si possono usare le freccette ed altri tasti per selezionare l’opzione desiderata. E fin qui nulla di nuovo sotto il sole, giusto?

L’attributo tabindex

Sebbene oggi il suo uso non sia visto di buon occhio, questo attributo aiuta molto a rendere accessibili modelli di componenti più complessi, con moduli ed elementi che devono seguire un ordine logico diverso da quello visualizzato nella pagina. Il suo utilizzo corretto serve a rendere focalizzabile da tastiera un elemento DOM che di suo non lo sarebbe. Vediamo le varie opzioni a nostra disposizione:

• tabindex="0" fa sì che l’elemento sia attivabile dalla tastiera. Pensiamo ad un <div> che ha la barra scorrevole al suo interno per qualche motivo (i progettisti grafici moderni sono molto creativi, parlo per esperienza 😅). Di suo, questo elemento non sarebbe focalizzabile, impedendo quindi a coloro che non hanno a disposizione la rotellina del mouse di vedere l’intero contenuto. Grazie a quest’attributo, possiamo risolvere questo problema in maniera semplice ed elegante.
• tabindex="-1" (o qualsiasi numero negativo), è per quelle situazioni dove serve ottenere l’effetto contrario, ovvero rimuovere un elemento che di suo sarebbe focalizzabile dalla sequenza di tabbing naturale della pagina. Pensiamo a quei siti che implementano varie sezioni a linguette all’interno di una pagina: le linguette (definite a volte prima dei contenuti di ogni linguetta) che non sono attive, non devono essere focalizzabili, perché il navigatore deve poter entrare nel contenuto della linguetta attiva.
• tabindex="2" (o qualsiasi numero maggiore di zero), renderà focalizzabile l’elemento, ma l’ordine sarà definito in base al numero intero utilizzato. Ciò vuol dire che prima la tastiera navigherà tutti gli elementi con valore 1, poi quelli con valore 2, e via dicendo. Quando tutti gli elementi con un tabindex positivo sono stati navigati, passerà agli elementi interattivi e quelli con l’attributo tabindex=”0″. Tieni in mente che il consorzio W3C sconsiglia fortemente di usare valori positivi: è meglio disporre gli elementi nel codice sorgente nell’ordine in cui dovrebbero essere focalizzabili, per evitare di confondere il navigante.

Allora forse sarebbe ideale aggiungere quest’attributo a tutti i tag all’interno di una pagina, per aiutare gli utenti di lettori vocali a navigare il sito più facilmente. In realtà nulla sarebbe più controproducente: chi usa uno screen reader ha sicuramente installato strumenti per navigare il web. Aggiungendo quest’attributo in maniera sconsiderata potrebbe interferire con quegli strumenti, risultando senza dubbio in qualche imprecazione un po’ pepata inviata al tuo indirizzo. Meglio lasciar fare il proprio mestiere ai tag semantici, invece che costringere il navigatore a pigiare quel povero tasto Tab miliardi di volte per arrivare al contenuto desiderato, non trovi?