ARIA: veleno o antidoto?

Aaron Leventhal

Che cos'è ARIA?

ARIA consente agli autori web di creare una realtà alternativa, visibile solo dagli screen reader.

A volte è necessario aggiungere dettagli alla verità o addirittura "mentire" per aiutare gli screen reader a capire cosa sta succedendo nei contenuti web. Ad esempio, "l'attenzione è qui" o "questo è un cursore". È come aggiungere magiche note adesive sopra gli strumenti e i widget della tua postazione di lavoro. Queste magiche note adesive fanno credere a tutti ciò che è scritto sopra.

Quando esiste una nota adesiva magica, questa sostituisce la nostra convinzione su cosa sia o faccia ogni strumento. Ad esempio, se aggiungi un'attributo ARIA che indica "questa cosa qui è una pistola per colla". Anche se si tratta di una scatola blu vuota, il magico post-it ci dice che si tratta di una pistola per colla. Possiamo anche aggiungere "ed è al 30% di completamento". Ora lo screen reader segnala che la pistola per colla è piena al 30%.

L'equivalente web è prendere un semplice div con un'immagine al suo interno e usare ARIA per indicare che si tratta di un cursore con un valore pari a 30 su 100. ARIA non rende div un cursore; dice semplicemente allo screen reader di dire che lo è.

ARIA non influisce sull'aspetto di una pagina web né sul comportamento di un utente che utilizza il mouse o la tastiera. Solo gli utenti delle tecnologie per la disabilità notano l'impatto di ARIA. Gli sviluppatori web possono aggiungere qualsiasi attributo ARIA arbitrario senza influire sugli utenti che non utilizzano una tecnologia per la disabilità.

Hai letto bene: ARIA non fa nulla per l'attenzione della tastiera o l'ordine di tabulazione. Tutto viene eseguito in HTML, a volte modificato con piccoli pezzi di JavaScript.

Come funziona ARIA?

A un browser viene chiesto da uno screen reader o da un'altra tecnologia di assistenza di fornire informazioni su ogni elemento. Quando ARIA è presente in un elemento, il browser acquisisce le informazioni e modifica ciò che dice allo screen reader in merito a quell'elemento.

Ecco alcuni casi d'uso comuni di ARIA.

• Aggiungi componenti speciali che non esistono in HTML, come il completamento automatico, un albero o un foglio di lavoro.
• Aggiungere componenti esistenti in HTML, ma che l'autore ha deciso di reinventare, possibly because they wanted to change the behavior or appearance of the standard element. Ad esempio, un elemento HTML <input type="range"> è fondamentalmente un cursore, ma gli autori vogliono che abbia un aspetto diverso.
  • Nella maggior parte dei casi, il problema può essere risolto con CSS. Tuttavia, per range, il CSS è imbarazzante. Gli autori possono creare il proprio dispositivo di scorrimento e utilizzare role="slider" con aria-valuenow per indicare alla tastiera il valore corrente.
• Includi regioni dinamiche per comunicare agli screen reader le modifiche pertinenti a un'area di una pagina.
• Crea punti di riferimento, ad esempio le intestazioni. I punti di riferimento aiutano gli utenti di screen reader a trovare più rapidamente ciò che cercano. I punti di riferimento possono contenere un'intera area correlata. Ad esempio, "questo contenitore è l'area principale della pagina" e "questo contenitore qui è un riquadro di navigazione".

Perché ARIA?

Può essere utile aggiungere un po' di ARIA a HTML che funziona già. Ad esempio, potremmo volere che un controllo del modulo indichi un avviso di messaggio di errore per un input non valido. In alternativa, potremmo voler indicare l'uso specifico di un input di testo. Queste modifiche possono rendere i siti web ordinari più utilizzabili con uno screen reader.

Esempio di barra dei menu

Supponiamo che il negozio web locale non venda tutti i widget di cui abbiamo bisogno. Ma siamo MacGyver. Possiamo inventare i nostri widget da altri widget. È abbastanza simile a un autore web che deve creare una barra dei menu.

Sebbene l'elemento <nav> esista, le barre dei menu vengono spesso messe insieme utilizzando div, immagini, pulsanti, gestori dei clic, gestori dei tasti premuti e ARIA.

Supportare gli utenti del mouse

Creiamo insieme una barra dei menu. Mostriamo una serie di elementi in caselle generiche chiamate div. Ogni volta che il nostro utente fa clic su un div, viene eseguito il comando corrispondente. Ottimo, funziona per chi usa il mouse.

Poi lo rendiamo bello. Utilizziamo il CSS per allineare gli elementi e applicare contorni visivi. La facciamo assomigliare abbastanza ad altre barre dei menu in modo che gli utenti di Sightly riconoscano intuitivamente che si tratta di una barra dei menu e sappiano come utilizzarla. La nostra barra dei menu utilizza anche un colore di sfondo diverso per qualsiasi elemento sopra il quale passa il mouse, fornendo all'utente un feedback visivo utile.

Alcune voci di menu sono principali. Generano sottomenu secondari. Ogni volta che l'utente passa il mouse sopra uno di questi elementi, avviamo un'animazione che fa scorrere il sottomenu secondario.

Tutto ciò è piuttosto inaccessibile, come accade di solito per molti elementi sul web.

Rendere accessibile la tastiera della barra dei menu

Aggiungiamo l'accessibilità della tastiera. Sono necessarie solo modifiche HTML e non ARIA. Ricorda che ARIA non influisce su aspetti fondamentali come aspetto, mouse o tastiera per gli utenti senza tecnologie per la disabilità.

Proprio come una pagina web può rispondere al mouse, può anche rispondere alla tastiera. Il nostro codice JavaScript può ascoltare tutte le sequenze di tasti che si verificano e decidere se la pressione dei tasti è utile. In caso contrario, lo rimanda alla pagina come un pesce troppo piccolo per essere mangiato. Le nostre regole sono le seguenti:

• Se l'utente preme un tasto freccia, esaminiamo i nostri modelli interni della barra dei menu e decidiamo quale deve essere la nuova voce di menu attiva. Cancelleremo tutte le evidenziazioni attuali e evidenzieremo il nuovo elemento del 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 consueta (in questo caso lo scorrimento della pagina).
• Se l'utente preme il tasto Invio, possiamo trattarlo 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, rimandalo alla pagina. Ad esempio, la nostra barra dei menu non ha bisogno del tasto Tab, quindi riponilo al suo posto. È difficile farlo bene. Ad esempio, la barra dei menu richiede i tasti freccia, ma non Alt+Freccia o Comando+Freccia. Si tratta di scorciatoie per passare alla pagina precedente e successiva nella cronologia web della scheda del browser. Se l'autore non fa attenzione, la barra dei menu li mangerà. Questo tipo di bug si verifica spesso e non abbiamo ancora iniziato con ARIA.

Accesso della barra dei menu allo screen reader

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

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

ARIA viene in soccorso. ARIA ci consente di far credere allo screen reader che lo stato attivo sia in una barra del menu. Se l'autore fa tutto correttamente, la nostra barra dei menu personalizzata apparirà allo screen reader come una barra dei menu in un'applicazione desktop.

La nostra prima bugia ARIA è l'attributo aria-activedescendant. Imposta l'attributo sull'ID della voce di menu attiva, avendo cura di aggiornarlo ogni volta che cambia. Ad esempio, aria-activedescendant="settings-menuitem". In questo modo, lo screen reader considererà il nostro elemento attivo ARIA come attivo, che viene letto ad alta voce o mostrato su un display braille.

Spiegazione di antenato, genitore e discendente

Il termine discendente si riferisce al fatto che un elemento è contenuto all'interno di un altro. Il termine opposto è antenato, ovvero un elemento è contenuto dagli antenati. Per il contenitore successivo verso l'alto/il basso, potrebbero essere utilizzati i termini più specifici principale/secondario. Ad esempio, immagina un documento con un paragrafo contenente un link. Il link è un paragrafo, ma ha anche il documento come elemento precedente. Al contrario, il documento può avere molti paragrafi secondari, ciascuno con link. I link sono tutti discendenti del documento bisnonno.

Se si utilizza aria-activedescendant per passare dalla barra dei menu attivata a una voce di menu specifica, lo screen reader ora sa dove si è spostato l'utente, ma non sa altro sull'oggetto. Cos'è questo elemento div? È qui che entra in gioco l'attributo ruolo. Utilizziamo role="menubar" sull'elemento contenente per l'intero elemento, poi role="menu" su gruppi di elementi e role="menuitem" sui singoli elementi del menu.

E se l'elemento menu può aprire un menu secondario? L'utente deve saperlo. Per un utente vedente, alla fine del menu potrebbe esserci una piccola immagine di un triangolo, ma lo screen reader non sa come leggere automaticamente le immagini, almeno per il momento. Possiamo aggiungere aria-expanded="false" su ogni elemento del menu espandibile per indicare che c'è qualcosa che può essere espandito e non è espanso. Inoltre, l'autore deve inserirerole="none" sul triangolo img per indicare che si tratta di contenuti solo a scopo estetico. In questo modo, lo screen reader non dirà nulla sull'immagine che sarebbe ridondante.

Correggere i bug della tastiera

Sebbene l'accesso alla tastiera sia parte dell'HTML di base, è facile da sovrascrivere. Ad esempio:

• Una casella di controllo utilizza la barra spaziatrice per attivare/disattivare, ma l'autore ha dimenticato di chiamarepreventDefault(). Ora la barra spaziatrice attiva/disattiva la casella di controllo e sposta la pagina verso il basso, che è il comportamento predefinito del browser per la barra spaziatrice.
• Una finestra di dialogo modale ARIA vuole bloccare la navigazione tra le schede al suo interno. Se l'autore dimenticato di consentire specificamente Control+Tab per aprire una nuova scheda mentre è nella finestra di dialogo, la funzionalità non funzionerà come previsto.
• Un autore crea un elenco di selezione e implementa i tasti su e giù. Tuttavia, l'autore deve ancora aggiungere i tasti Home, Fine, Freccia su, Freccia giù o la navigazione con la prima lettera.

Gli autori devono seguire schemi noti. Per ulteriori informazioni, consulta la sezione Risorse.

Per problemi di accesso alla tastiera, è utile provare anche senza uno screen reader o con la modalità del browser virtuale disattivata. Puoi scoprire i bug della tastiera senza uno screen reader, poiché l'accesso alla tastiera è implementato con HTML, non con ARIA. Dopotutto, ARIA non influisce sul comportamento della tastiera o del mouse, ma inganna lo screen reader su ciò che è contenuto nella pagina web, sull'elemento attualmente attivo e così via.

I bug della tastiera sono quasi sempre un bug nei contenuti web, in particolare in HTML e JavaScript, non in ARIA.

Perché ce ne sono così tanti?

Esistono molti modi in cui un autore può commettere errori con ARIA. Ogni errore comporta un guasto completo o differenze sottili. I problemi più sottili potrebbero essere peggiori, perché è improbabile che l'autore li rileve prima della pubblicazione.

Dopotutto, a meno che l'autore non sia un utente esperto di screen reader, qualcosa andrà storto in ARIA. Nel nostro esempio di barra dei menu, l'autore potrebbe pensare che il ruolo "option" debba essere utilizzato quando "menuitem" è corretto. Potrebbero dimenticare di utilizzare aria-expanded, di impostare e cancellare aria-activedescendant al momento giusto o di avere una barra dei menu contenente gli altri menu. E che dire del conteggio dei piatti del menu? Di solito gli elementi del menu vengono presentati dagli screen reader con qualcosa come "elemento 3 di 5" in modo che l'utente sappia dove si trova. In genere, il browser li conteggia automaticamente, ma in alcuni casi e in alcune combinazioni di browser e screen reader potrebbero essere calcolati numeri errati e l'autore dovrebbe sostituirli con aria-posinset e aria-setsize.

E queste sono solo barre dei menu. Pensa a quanti tipi di widget esistono. Se vuoi, dai un'occhiata alle specifiche ARIA o alle pratiche di creazione. Per ogni pattern, esistono una dozzina di modi in cui ARIA potrebbe essere usata in modo improprio. ARIA si basa sul fatto che gli autori sappiano cosa stanno facendo. Cosa potrebbe andare storto, dato che la maggior parte degli autori non utilizza screen reader?

In altre parole, è assolutamente necessario che gli utenti che utilizzano effettivamente gli screen reader provino i widget ARIA prima che vengano considerati idonei alla spedizione. Ci sono troppe sfumature. Idealmente, sarebbe opportuno provare tutto con diverse combinazioni di browser e screen reader, a causa delle numerose peculiarità di implementazione, oltre ad alcune implementazioni incomplete.

Riepilogo

ARIA può essere utilizzata per sostituire o aggiungere qualsiasi elemento dell'HTML. Può apportare piccole modifiche alla presentazione dell'accessibilità o creare un'intera esperienza. Per questo motivo, ARIA è incredibilmente potente, ma anche pericoloso nelle mani dei nostri sviluppatori che non sono utenti di screen reader.

ARIA è un livello di markup che sostituisce altre scelte. Quando uno screen reader chiede cosa sta succedendo, se esiste ARIA, l'utente riceve la versione ARIA della verità.

Risorse aggiuntive

Le norme di scrittura ARIA del W3C documentano le caratteristiche importanti della navigazione da tastiera di ogni esempio e forniscono JavaScript, CSS e ARIA funzionanti. Gli esempi si concentrano su ciò che funziona oggi e non coprono i dispositivi mobili.

Che cos'è un'API di accessibilità?

Un'API di accessibilità è il modo in cui uno screen reader o un'altra tecnologia per la disabilità sa cosa c'è nella pagina e cosa sta succedendo. Alcuni esempi sono MSAA, IA2 e UIA. Un'API di accessibilità è composta da due parti:

• Un "albero" di oggetti che rappresenta una gerarchia di contenitori. Ad esempio, un documento può contenere una serie di paragrafi. Un paragrafo può contenere testo, immagini, link e decorazioni di testo. Ogni elemento della struttura ad albero degli oggetti può avere proprietà, come il ruolo (che cosa sono?), un nome o un'etichetta, un valore inserito dall'utente, una descrizione e stati booleani, come attivabile, attivo, obbligatorio, selezionato. ARIA può eseguire l'override di qualsiasi di queste proprietà.
  • Gli screen reader utilizzano la struttura ad albero per aiutare gli utenti a navigare in modalità di buffer virtuale, ad esempio "Vai all'intestazione successiva".
• Una serie di eventi che descrivono le modifiche all'albero, ad esempio "Il focus è ora qui". Lo screen reader utilizza gli eventi per comunicare all'utente cosa è appena accaduto. Quando il markup HTML o ARIA importante cambia, viene attivato un evento per indicare allo screen reader che è cambiato qualcosa.

HTML si mappa bene a queste API di accessibilità. Quando l'HTML non è sufficiente, è possibile aggiungere ARIA per consentire al browser di sostituire la semantica HTML prima di inviare la struttura ad albero degli oggetti o gli eventi allo screen reader.