L'albero dell'accessibilità

Introduzione all'albero dell'accessibilità

Alice Boxhall

Dave Gash

Meggin Kearney

Immagina di dover creare un'interfaccia utente solo per utenti di screen reader. In questo caso, non devi creare alcuna UI visiva, ma devi solo fornire informazioni sufficienti per lo screen reader.

Quello che creerai è un tipo di API che descrive la struttura della pagina, simile all'API DOM, ma con meno informazioni e meno nodi ci si può sbagliare perché molte di queste informazioni sono utili solo per una presentazione visiva. Potrebbe avere il seguente aspetto.

È essenzialmente ciò che il browser presenta allo screen reader. Il browser prende l'albero DOM e lo modifica in un formato utile per le tecnologie per la disabilità. Ci riferiamo a questo albero modificato come Albero per l'accessibilità.

Potresti visualizzare l'albero dell'accessibilità come una vecchia pagina web degli anni '90: alcune immagini, molti link, magari un campo e un pulsante.

La scansione visiva di una pagina come in questo caso ti offre un'esperienza simile a quella di uno screen reader. L'interfaccia è già presente, ma è semplice e diretta, molto simile a un'interfaccia ad albero dell'accessibilità.

L'albero dell'accessibilità è ciò con cui interagisce la maggior parte delle tecnologie per la disabilità. Il flusso è simile a questo.

1. Un'applicazione (il browser o un'altra app) espone una versione semantica della UI alla tecnologia per la disabilità tramite un'API.
2. La tecnologia per la disabilità può utilizzare le informazioni lette 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 sente una rappresentazione vocale dell'app.
3. La tecnologia per la disabilità può anche consentire all'utente di interagire con l'app in modo diverso. Ad esempio, la maggior parte degli screen reader fornisce hook per consentire all'utente di simulare facilmente un clic del mouse o un tocco del dito.
4. La tecnologia per la disabilità trasmette l'intent dell'utente (ad esempio, "clic") all'app tramite l'API Accessibility. L'app ha quindi la responsabilità di interpretare l'azione in modo appropriato nel contesto della UI originale.

Per i browser web c'è un passaggio in più in ogni direzione, perché il browser è di fatto una piattaforma per le app web che vengono eseguite al suo interno. Il browser deve quindi tradurre l'app web in una struttura ad albero dell'accessibilità e assicurarsi che gli eventi appropriati vengano attivati in JavaScript in base alle azioni dell'utente provenienti dalle tecnologie per la disabilità.

Ma questa è tutta responsabilità del browser. Il nostro compito di sviluppatori web è essere consapevoli dell'esistenza di questa situazione e sviluppare pagine web che sfruttino questo processo per creare un'esperienza accessibile per i nostri utenti.

Lo facciamo assicurando di esprimere correttamente la semantica delle nostre pagine, assicurandoci che gli elementi importanti nella pagina abbiano i ruoli, gli stati e le proprietà di accessibilità corretti e che specifichiamo nomi e descrizioni accessibili. Il browser può quindi consentire alla tecnologia per la disabilità di accedere ai dati per creare un'esperienza personalizzata.

Semantica nell'HTML nativo

Un browser può trasformare l'albero del DOM in un albero dell'accessibilità perché gran parte del DOM ha un significato semantico implicito. In altre parole, il DOM utilizza elementi HTML nativi che sono riconosciuti dai browser e funzionano in modo prevedibile su diverse piattaforme. L'accessibilità di elementi HTML nativi come link o pulsanti viene quindi gestita automaticamente. Possiamo trarre vantaggio da questa accessibilità incorporata scrivendo codice HTML che esprima la semantica degli elementi della pagina.

Tuttavia, a volte usiamo elementi che hanno l'aspetto di elementi nativi, ma non lo sono. Ad esempio, questo "pulsante" non è affatto un pulsante.

Può essere creato in HTML in vari modi; uno è illustrato di seguito.

<div class="button-ish">Give me tacos</div>

Quando non utilizziamo un effettivo elemento pulsante, lo screen reader non ha modo di sapere a cosa è stato indirizzato. Inoltre, avremmo dovuto svolgere il lavoro aggiuntivo di aggiunta di tabindex per renderlo utilizzabile dagli utenti solo da tastiera perché, poiché ora è codificato, può essere utilizzato solo con un mouse.

Possiamo facilmente risolvere questo problema utilizzando un elemento button standard anziché un div. Un elemento nativo ha anche il vantaggio di occuparci delle interazioni da tastiera. Ricorda che non devi perdere gli effetti visivi accattivanti solo perché utilizzi un elemento nativo; puoi applicare uno stile agli elementi nativi per soddisfarli nel modo che preferisci senza rinunciare alla semantica e al comportamento impliciti.

In precedenza abbiamo accennato al fatto che gli screen reader annunceranno il ruolo, il nome, lo stato e il valore di un elemento. Vengono trattati l'elemento semantico, il ruolo, lo stato e il valore corretti, ma dobbiamo anche garantire che il nome di un elemento sia rilevabile.

In generale, ci sono due tipi di nomi:

• Etichette visibili, utilizzate da tutti gli utenti per associare il significato a un elemento, e
• Alternative di testo, utilizzate solo quando non è necessaria un'etichetta visiva.

Per gli elementi a livello di testo non occorre fare nulla, perché per definizione avrà alcuni contenuti testuali. Tuttavia, per gli elementi di input o di controllo e i contenuti visivi come le immagini, dobbiamo specificare un nome. Infatti, fornire alternative di testo per qualsiasi contenuto non testuale è la prima voce dell'elenco di controllo di WebAIM.

Un modo per farlo è seguire il consiglio che indica che agli input del modulo sono associate etichette di testo. Ci sono 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 dei clic per la casella di controllo, il che è utile anche per gli utenti del mouse o del touchscreen. Per associare un'etichetta a un elemento:

• Posiziona l'elemento di input all'interno di un elemento di etichetta

<label>
    <input type="checkbox">Receive promotional offers?
</label>

o

• Utilizza l'attributo for dell'etichetta e fai riferimento al valore id dell'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 il ruolo di casella di controllo, è in stato selezionato e ha il nome "Vuoi ricevere offerte promozionali?".