Introduzione all'albero di accessibilità
Immagina di creare un'interfaccia utente solo per gli utenti di screen reader. In questo caso, non è necessario creare alcuna UI visiva, ma è sufficiente fornire informazioni sufficienti per lo screen reader.
Quello che creeresti è una sorta di API che descrive la struttura della pagina, simile all'API DOM, ma puoi cavartela con meno informazioni e meno nodi, perché molte di queste informazioni sono utili solo per la presentazione visiva. Potrebbe avere un aspetto simile al seguente.
In pratica, questo è ciò che il browser presenta effettivamente allo screen reader. Il browser prende l'albero DOM e lo modifica in un formato utile per le tecnologie per la disabilità. Questo albero modificato è chiamato albero di accessibilità.
Puoi immaginare l'albero di accessibilità come una vecchia pagina web degli anni '90: alcune immagini, molti link, forse un campo e un pulsante.
Scorrendo visivamente una pagina come questa, l'esperienza è simile a quella di un utente di screen reader. L'interfaccia è presente, ma è semplice e diretta, molto simile a un'interfaccia ad albero di accessibilità.
L'albero di accessibilità è l'elemento con cui interagisce la maggior parte delle tecnologie per la disabilità. Il flusso è più o meno questo.
- Un'applicazione (il browser o un'altra app) espone una versione semantica della sua UI alle tecnologie per la disabilità tramite un'API.
- La tecnologia per la disabilità può utilizzare le informazioni che legge tramite l'API per creare una presentazione alternativa dell'interfaccia utente per l'utente. Ad esempio, uno screen reader crea un'interfaccia in cui l'utente ascolta una rappresentazione vocale dell'app.
- La tecnologia per la disabilità potrebbe anche consentire all'utente di interagire con l'app in un modo diverso. Ad esempio, la maggior parte degli screen reader fornisce hook per consentire a un utente di simulare facilmente un clic del mouse o un tocco con il dito.
- La tecnologia per la disabilità trasmette lo user intent (ad esempio "fai clic") all'app tramite l'API per l'accessibilità. L'app ha quindi la responsabilità di interpretare l'azione in modo appropriato nel contesto della UI originale.
Per i browser web, è previsto un passaggio aggiuntivo in ogni direzione, perché il browser è di fatto una piattaforma per le app web eseguite al suo interno. Il browser deve quindi tradurre l'app web in un albero di accessibilità e deve assicurarsi che gli eventi appropriati vengano attivati in JavaScript in base alle azioni dell'utente provenienti dalle tecnologie per la disabilità.
Ma tutto questo è responsabilità del browser. Il nostro compito di sviluppatori web è semplicemente quello di essere consapevoli di ciò che sta accadendo e di sviluppare pagine web che sfruttino questo processo per creare un'esperienza accessibile per i nostri utenti.
Per farlo, ci assicuriamo di esprimere correttamente la semantica delle nostre pagine: verifichiamo che gli elementi importanti della pagina abbiano i ruoli, gli stati e le proprietà accessibili corretti e specifichiamo nomi e descrizioni accessibili. Il browser può quindi consentire alle tecnologie per la disabilità di accedere a queste informazioni per creare un'esperienza personalizzata.
Semantica in HTML nativo
Un browser può trasformare l'albero DOM in un albero di accessibilità perché gran parte del DOM ha un significato semantico implicito. In altre parole, il DOM utilizza elementi HTML nativi riconosciuti dai browser e che funzionano in modo prevedibile su una varietà di piattaforme. L'accessibilità per gli elementi HTML nativi, come link o pulsanti, viene quindi gestita automaticamente. Possiamo sfruttare questa accessibilità integrata scrivendo codice HTML che esprima la semantica degli elementi di pagina.
Tuttavia, a volte utilizziamo elementi che sembrano nativi, ma non lo sono. Ad esempio, questo "pulsante" non è affatto un pulsante.
Potrebbe essere costruito in HTML in diversi modi; uno di questi è mostrato di seguito.
<div class="button-ish">Give me tacos</div>
Quando non utilizziamo un elemento button effettivo, lo screen reader non ha modo di sapere su cosa è arrivato. Inoltre, dovremmo fare il lavoro extra di aggiungere tabindex per renderlo utilizzabile dagli utenti che usano solo la tastiera perché, così come è codificato ora, può essere utilizzato solo con un mouse.
Possiamo risolvere facilmente questo problema utilizzando un normale elemento button anziché div.
L'utilizzo di un elemento nativo ha anche il vantaggio di gestire le interazioni con la tastiera per noi. E ricorda che non devi rinunciare ai tuoi fantastici effetti visivi solo perché utilizzi un elemento nativo; puoi applicare uno stile agli elementi nativi per farli apparire come vuoi, mantenendo comunque la semantica e il comportamento impliciti.
In precedenza abbiamo notato che gli screen reader annunciano il ruolo, il nome, lo stato e il valore di un elemento. Utilizzando l'elemento semantico corretto, il ruolo, lo stato e il valore sono coperti, ma dobbiamo anche assicurarci di rendere rilevabile il nome di un elemento.
In generale, esistono due tipi di nomi:
- Etichette visibili, utilizzate da tutti gli utenti per associare un significato a un elemento.
- Testi alternativi, che vengono utilizzati solo quando non è necessaria un'etichetta visiva.
Per gli elementi a livello di testo, non dobbiamo fare nulla, perché per definizione avranno dei contenuti di testo. Tuttavia, per gli elementi di input o di controllo e i contenuti visivi come le immagini, dobbiamo assicurarci di specificare un nome. In effetti, fornire alternative testuali per i contenuti non testuali è il primo elemento dell'elenco di controllo di WebAIM.
Un modo per farlo è seguire il consiglio "Gli input dei moduli hanno etichette di testo associate". Esistono due modi per associare un'etichetta a un elemento del modulo, ad esempio una casella di controllo. Entrambi i metodi fanno sì che il testo dell'etichetta diventi anche un target di clic per la casella di controllo, il che è utile anche per gli utenti di mouse o touchscreen. Per associare un'etichetta a un elemento, puoi:
- Posiziona l'elemento di input all'interno di un elemento etichetta
<label>
<input type="checkbox">Receive promotional offers?
</label>o
- Utilizza l'attributo
fordell'etichetta e fai riferimento all'attributoiddell'elemento
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Quando la casella di controllo è stata etichettata correttamente, lo screen reader può segnalare che l'elemento ha un ruolo di casella di controllo, è in uno stato selezionato e si chiama "Vuoi ricevere offerte promozionali?".
