ARIA: veleno o antidoto?

In che modo mentire agli screen reader migliora l'accessibilità, se non ci mette del sale!

Che cos'è ARIA?

ARIA consente agli autori web di creare una realtà alternativa, che viene vista solo dagli screen reader 🤥

A volte è necessario spiegare agli screen reader cosa sta succedendo nei contenuti web e basarsi su ciò che accade nei contenuti web. Ad esempio, "l'obiettivo è davvero qui!" oppure "questo è davvero un cursore!". È come aggiungere magiche note adesive sopra strumenti e widget sul tuo workbench. Queste magiche note adesive fanno credere a tutti ciò che è scritto su di esse.

Ogni volta che esiste una nota adesiva magica, sostituisce la nostra convinzione su cosa sia ogni strumento o qualcosa su di esso. Esempio: "questa cosa qui è una pistola per colla!". Anche se in realtà è ancora una scatola blu vuota sul banco da lavoro, la magica nota adesiva ci farà vedere che è una pistola per colla. Possiamo anche aggiungere "ed è pieno al 30%". Lo screen reader riporterà la presenza di una pistola per colla piena al 30%.

L'equivalente per il Web consiste nel prendere un elemento box normale (un div) con un'immagine al suo interno e utilizzare ARIA per dire che è un dispositivo di scorrimento con valore 30 su 100.

Che cosa non è ARIA?

Il feed ARIA non influisce sull'aspetto di una pagina web o sul comportamento degli utenti che utilizzano il mouse o la tastiera. Solo gli utenti di tecnologie per la disabilità noteranno differenze da ARIA. Gli sviluppatori web possono aggiungere qualsiasi URL ARIA arbitrario senza influire sugli utenti che non utilizzano tecnologie per la disabilità.

Hai capito bene: ARIA non fa nulla per lo stato attivo della tastiera o per l'ordine delle schede. Tutto questo viene fatto in HTML, a volte modificato con frammenti di JavaScript.

Come funziona ARIA?

Ai browser viene chiesto da uno screen reader o da un'altra tecnologia per la disabilità le informazioni su ciascun elemento. Quando ARIA è presente su un elemento, il browser acquisisce le informazioni e cambia cosa dice allo screen reader in merito all'elemento.

Perché ARIA?

Perché mai dovremmo mentire ai nostri utenti?!

Supponiamo che il web store locale non venda tutti i widget di cui abbiamo bisogno. Ma siamo MacGyver, dannazione. Possiamo semplicemente inventare i nostri widget da altri widget. FWIW, le sette cose più usate di MacGyver sono coltelli, gomme, fili da scarpe, fiammiferi, graffette, candele di compleanno e nastro adesivo svizzero. Li usa per costruire bombe e altri oggetti che non si trovano solo in giro. È un processo molto simile a un autore web che deve creare una barra dei menu. Le barre dei menu sono così utili che pensi possano fa parte dell'HTML, ma non lo è. Oh beh! Non pensavi che gli autori sarebbero stati soddisfatti di link e pulsanti, vero? Pertanto, l'autore ne creerà una combinazione utilizzando gli strumenti che preferisce: divs, images, style, click handler, keypress gestori, spit e ARIA.

A volte, anziché utilizzare il valore ARIA al massimo, lo utilizziamo solo come miglioramento. Può essere utile aggiungere un po' di ARIA su un codice HTML che già funziona sostanzialmente. Ad esempio, potremmo volere che un controllo modulo punti a un avviso di messaggio di errore relativo a un input non valido. Oppure potremmo voler indicare che una casella di testo è per la ricerca. Con queste piccole modifiche, i normali siti web possono essere utilizzati con uno screen reader.

Esempio di barra dei menu

Supporto degli utenti che fanno clic sul mouse

Creiamo insieme una barra dei menu. Mostriamo una serie di elementi all'interno di riquadri generici chiamati div. Ogni volta che l'utente fa clic su un div, esegue il comando corrispondente. Fantastico, funziona per chi fa clic sul mouse.

Poi lo facciamo splendido. Usiamo i CSS, ovvero gli stili, per allineare bene gli elementi e aggiungere contorni visivi intorno. Lo rendiamo abbastanza simile ad altre barre dei menu da sapere intuitivamente che si tratta di una barra dei menu e come utilizzarla. La barra dei menu usa anche un colore di sfondo diverso per ogni elemento su cui si trova il mouse, fornendo all'utente un utile feedback visivo.

Alcune voci di menu sono principali. Generano sottomenu di bambini. Quando l'utente passa il mouse sopra una di queste, avviiamo un'animazione che fa scorrere il sottomenu.

Ovviamente tutto questo è inaccessibile, come di consueto per molte cose sul web, soprattutto perché gli standard HTML non aggiungevano tutto ciò di cui un autore web ha bisogno. E anche se fosse così, gli autori web vorranno sempre inventare comunque la loro versione speciale.

Rendere accessibile la tastiera della barra dei menu

Come primo passo verso l'accessibilità, aggiungiamo l'accessibilità della tastiera. Questa parte utilizza solo HTML e non ARIA. Ricorda che ARIA non influisce su aspetti principali come aspetto, mouse o tastiera per gli utenti senza tecnologie per la disabilità.

Così come una pagina web può rispondere al mouse, può anche rispondere alla tastiera. Il nostro JavaScript ascolterà tutte le sequenze di tasti che si verificano e deciderà se la pressione dei tasti è utile. In caso contrario, lo riporta nella pagina come un pesce troppo piccolo per essere mangiato. Le nostre regole sono simili a:

• Se l'utente preme un tasto freccia, diamo un'occhiata ai progetti della nostra barra dei menu interna e decidiamo quale debba essere la nuova voce di menu attiva. Cancelleremo tutte le caratteristiche in evidenza ed evidenzieremo la nuova voce di menu in modo che l'utente vedente sappia visivamente dove si trova. La pagina web deve quindi chiamare event.preventDefault() per impedire al browser di eseguire l'azione abituale (in questo caso scorrere la pagina).
• Se l'utente preme il tasto Invio, possiamo considerarlo come un clic ed eseguire l'azione appropriata (o persino aprire un altro menu).
• Se l'utente preme un tasto che dovrebbe fare qualcos'altro, non mangiarlo. Torna alla pagina come previsto. Ad esempio, la barra dei menu non richiede il tasto Tab, quindi torna indietro. È difficile da capire e gli autori spesso lo rovinano. Ad esempio, nella barra dei menu sono necessari i tasti freccia, ma non Alt+Freccia o Comando+Freccia. Queste sono scorciatoie per passare alla pagina precedente/successiva nella cronologia web della scheda del browser. Se l'autore non fa attenzione, la barra dei menu le mangia. Questo tipo di bug è presente molto e non abbiamo ancora iniziato con ARIA.

Accesso tramite screen reader alla barra dei menu

La barra dei menu è stata creata con nastro adesivo e div. Di conseguenza, uno screen reader non ha idea di cosa sia. Il colore di sfondo dell'elemento attivo è solo un colore. I div delle voci di menu sono semplici oggetti senza un significato particolare. Di conseguenza, un utente della nostra barra dei menu non riceve istruzioni sui tasti da premere o sull'elemento su cui è impostato.

Ma non è giusto! La barra dei menu non è male per l'utente vedente.

ARIA in soccorso. ARIA ci consente di simulare lo screen reader che si trova in una barra dei menu. Se l'autore fa tutto correttamente, la nostra barra dei menu personalizzata sarà visualizzata dallo screen reader come la barra dei menu di un'applicazione desktop.

La prima, ehm, ARIA bugi, consiste nell'utilizzare l'attributo aria-activedescendant e impostarlo sull'ID della voce di menu attualmente attiva, facendo attenzione ad aggiornarlo ogni volta che cambia. Ad esempio, aria-activedescendant="settings-menuitem". Con questa piccola bugia bianca lo screen reader considera l'elemento attivo ARIA come elemento attivo, che viene letto ad alta voce o mostrato su un display braille.

Torna a aria-activedescendant. Usandolo per puntare dalla barra dei menu attiva a una voce di menu specifica, lo screen reader ora sa dove si è spostato l'utente, ma non fa altro che riguarda l'oggetto. Che cos'è questo elemento div? È qui che entra in gioco l'attributo Role. Utilizziamo role="menubar" sull'elemento contenitore per l'intero elemento, poi usiamo role="menu" su gruppi di elementi e role="menuitem" su... rullo di tamburo... per le singole voci del menu.

E se la voce di menu porta a un menu secondario? L'utente deve saperlo, giusto? Per un utente vedente, potrebbe essere presente una piccola immagine di un triangolo alla fine del menu, ma lo screen reader non sa leggere automaticamente le immagini, almeno a questo punto. Possiamo aggiungere aria-expanded="false" a ogni voce di menu espandibile per indicare che 1) è possibile espandere un elemento e 2) che al momento non lo è. Come tocco aggiuntivo, l'autore deve inserire role="none" nel triangolo img per indicare che è solo a scopo di pretificazione. Ciò impedisce allo screen reader di fornire informazioni sull'immagine che potrebbero essere ridondanti e potenzialmente fastidiose.

Gestione dei bug

Bug relativi alla tastiera (HTML!)

Anche se l'accesso da tastiera fa parte del codice HTML di base, gli autori lo sbagliano continuamente, perché non usano molto la navigazione da tastiera o perché esistono molte sfumature.

Esempi di bug:

• Una casella di controllo utilizza la barra spaziatrice per attivare/disattivare, ma l'autore ha dimenticato di chiamare preventDefault(). Ora la barra spaziatrice attiva o disattiva la casella di controllo e la pagina giù, che è il comportamento predefinito del browser per la barra spaziatrice.
• Una finestra di dialogo modale ARIA vuole bloccare la navigazione delle schede al suo interno e l'autore dimentica di consentire in modo specifico Ctrl+Tab nel browser. Ora, premendo Ctrl+Tab puoi semplicemente navigare nella finestra di dialogo e non cambiare scheda nel browser come dovrebbe. Ehm.
• Un autore crea un elenco di selezione e implementa up/down, ma non implementa home/end/pageup/pagedown o la navigazione nella prima lettera.

Gli autori devono seguire schemi noti. Per saperne di più, consulta la sezione Risorse.

Per problemi di puro accesso tramite tastiera, è utile provare anche senza uno screen reader o con la modalità del browser virtuale disattivata. In genere gli screen reader non sono necessari per individuare bug relativi alla tastiera e l'accesso da tastiera viene implementato in HTML, non in ARIA. Dopotutto, ARIA non influisce su elementi di base come il comportamento della tastiera o del mouse, ma riguarda solo lo screen reader il contenuto della pagina web, l'elemento attivo al momento e così via.

I bug relativi alle tastiere sono quasi sempre un bug nei contenuti web, in particolare nel codice HTML e JavaScript, non in ARIA.

Bug ARIA: perché ce ne sono così tanti?

Gli autori possono commettere errori nel formato ARIA in moltissimi aspetti, ciascuno dei quali porterà a interruzioni o a sottili differenze. Quelle più sottili sono probabilmente peggio, perché l'autore non ne rileva la maggior parte prima della pubblicazione.

Dopo tutto, a meno che l'autore non sia un utente esperto di screen reader, si verificherà un problema in ARIA. Nell'esempio della barra dei menu, l'autore potrebbe pensare che il ruolo di "opzione" debba essere utilizzato quando "voce di menu" era corretto. Potrebbero dimenticarsi di utilizzare aria-expanded, di impostare e cancellare aria-activedescendant al momento giusto o di avere una barra dei menu con gli altri menu. E per quanto riguarda il conteggio delle voci del menu? Di solito, le voci di menu vengono presentate dagli screen reader con "voce 3 di 5"" per far sapere all'utente dove si trova. In genere questo viene conteggiato automaticamente dal browser, ma in alcuni casi, e in alcune combinazioni browser-screen reader, potrebbero essere calcolati i numeri sbagliati e l'autore dovrebbe sostituire questi numeri con aria-posinset e aria-setsize.

Sono solo barre dei menu. Pensa a quanti tipi di widget esistono. Dai un'occhiata alla specifica ARIA o alle pratiche di creazione, se vuoi. Per ogni pattern esistono decine di modi in cui ARIA può essere utilizzato in modo improprio. ARIA si affida agli autori per sapere quello che fanno. Cosa potrebbe andare storto, dato che molti autori non sono utenti di screen reader?

In altre parole, agli utenti effettivi di screen reader è necessario provare i widget ARIA prima che siano considerati spedibili. Ci sono troppe sfumature. Idealmente, tutto verrebbe provato con diverse combinazioni di screen reader del browser, a causa dei numerosi difetti di implementazione e di alcune implementazioni incomplete.

Riepilogo

In sintesi, ARIA magic può essere utilizzato per sostituire o aggiungere elementi a tutto ciò che indica l'HTML. Può essere usato per apportare piccole modifiche alla presentazione di accessibilità o per creare un'intera esperienza. Questo è il motivo per cui ARIA è incredibilmente potente, ma allo stesso tempo pericoloso per le mani dei nostri amichevoli autori web locali che in genere non utilizzano gli screen reader da soli.

ARIA è solo un semplice livello di markup per la sostituzione dei dati. Quando uno screen reader chiede cosa sta succedendo, se esiste ARIA, riceve la versione ARIA della verità anziché quella reale di base.

Appendice 1: risorse aggiuntive

Riferimento ibrido con informazioni sulla tastiera ed esempi di codice

• Pratiche di authoring ARIA di W3C: documenta le importanti caratteristiche di navigazione da tastiera di ogni esempio e fornisce un codice JS/CSS/ARIA funzionante. Gli esempi si riferiscono a ciò che funziona oggi e non riguardano i dispositivi mobili.

Addendum 2: Per cosa viene più utilizzato ARIA?

Perché ARIA può sostituire o integrare piccole o grandi informazioni, in genere utile per dire cose che interessano allo screen reader.

Ecco alcuni utilizzi comuni di ARIA.

• Widget speciali che non esistono nel codice HTML, come la barra dei menu, il completamento automatico, la struttura ad albero o un foglio di lavoro.
• Widget che esistono in HTML, ma che l'autore ne ha inventato comunque uno proprio, probabilmente perché ha dovuto modificare il comportamento o l'aspetto del widget normale. Ad esempio, un elemento HTML <input type="range"> è fondamentalmente un dispositivo di scorrimento, ma gli autori vogliono cambiarne l'aspetto. Per la maggior parte dei casi, è possibile utilizzare CSS, ma per input type="range" il codice CSS è complicato. Un autore può creare il proprio cursore e utilizzare role="slider" con aria-valuenow per indicare il valore attuale.
• Le regioni in diretta indicano agli screen reader "in questa area della pagina qualsiasi modifica vale la pena dire all'utente".
• Punti di riferimento (HTML ha ora equivalenti). Sono simili alle intestazioni, in quanto aiutano gli utenti di screen reader a trovare più rapidamente ciò che cercano. Tuttavia, sono diversi in quanto contengono l'intera area correlata. Ad esempio, "questo contenitore è l'area principale della pagina" e "il contenitore qui è un pannello di navigazione".

Addendum 3: Che cos'è un'API Accessibility?

Un'API Accessibility è il modo in cui uno screen reader o un altro AT sa cosa c'è nella pagina e cosa sta succedendo in questo momento. Alcuni esempi sono MSAA, IA2 e UIA. È solo Windows! Un'API Accessibility è composta da due parti:

• Un "albero" di oggetti che rappresenta una gerarchia di container. Sono come le bambole russe che nidificano, ma ogni bambola può contenere diverse altre bambole. Ad esempio, un documento può contenere una serie di paragrafi e un paragrafo può contenere testo, immagini, link, grassetto e così via. Ogni elemento nell'albero dell'oggetto può avere proprietà quali un ruolo (che cosa sono?), un nome/etichetta, un valore inserito dall'utente, una descrizione, nonché stati booleani come attivabile, attivo, obbligatorio e selezionato. ARIA può eseguire l'override di queste proprietà. Lo screen reader utilizza la struttura ad albero per aiutare l'utente a navigare in modalità buffer virtuale, ad esempio "vai all'intestazione successiva".
• Una serie di eventi che si verificano a descrivere le modifiche apportate all'albero, come "l'attenzione è ora al di sopra!". Lo screen reader utilizza gli eventi per comunicare all'utente cosa è appena accaduto. Quando vengono apportate importanti modifiche al markup HTML o ARIA, viene attivato un evento per indicare allo screen reader che è cambiato qualcosa.

Di solito gli autori utilizzano semplicemente il codice HTML, che si mappa correttamente con queste API di accessibilità. Quando il codice HTML non è sufficiente, viene utilizzato ARIA e il browser sostituisce la semantica HTML prima di inviare la struttura ad albero degli oggetti o gli eventi allo screen reader.