ARIA: veleno o antidoto?

Che cos'è l'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 di 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.

Di seguito sono riportati alcuni utilizzi comuni di ARIA.

• Aggiungi componenti speciali che non esistono nel codice HTML, come il completamento automatico, una struttura 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, è possibile risolvere questo problema utilizzando il 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 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. Oppure 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.

Supporta gli utenti del mouse

Creiamo insieme una barra dei menu. Mostriamo vari elementi all'interno di riquadri generici chiamati 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, diamo un'occhiata ai progetti della barra dei menu interna 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 puoi riutilizzarlo. È difficile fare la cosa giusta. 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 della 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 tramite screen reader alla barra dei menu

La nostra 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 è semplicemente un colore. I div delle voci di menu sono solo oggetti semplici senza un significato particolare. Di conseguenza, un utente della barra dei menu non riceve istruzioni sui tasti da premere o sulla voce che 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". Di conseguenza, lo screen reader considera attivo l'elemento ARIA come elemento attivo, che viene letto ad alta voce o mostrato su un display braille.

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. Che cos'è comunque 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" su … rullo di tamburi … i 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" a ogni voce di menu espandibile per indicare che c'è qualcosa che può essere espanso e non. 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 con le schede al suo interno. Se l'autore dimenticato di consentire specificamente Ctrl+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 Freccia su e giù. Tuttavia, l'autore deve comunque aggiungere la navigazione con Home, Fine, Pagina su, Pagina giù o la prima lettera.

Gli autori devono seguire schemi noti. Consulta la sezione Risorse per saperne di più.

Per problemi puramente di accesso alla tastiera, è utile fare un tentativo senza uno screen reader o con la modalità browser virtuale disattivata. Puoi scoprire bug della tastiera senza uno screen reader, in quanto l'accesso alla tastiera viene implementato con il codice HTML, non con l'ARIA. Dopotutto, ARIA non influisce sul comportamento della tastiera o del mouse, ma inganna lo screen reader su ciò che è presente 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é 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, si verifica un problema 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. Solitamente viene conteggiato automaticamente dal browser, ma in alcuni casi, e in alcuni browser, con combinazioni di screen reader, potrebbero essere calcolati i numeri sbagliati 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, è necessario che gli utenti effettivi di screen reader provino i widget ARIA prima che vengano considerati spedibili. Ci sono troppe sfumature. L'ideale sarebbe provare tutto con diverse combinazioni di browser-screen reader, a causa delle numerose difficoltà di implementazione, oltre ad alcune implementazioni incomplete.

Riepilogo

ARIA può essere utilizzato per sostituire o aggiungere elementi a qualsiasi elemento indicato nell'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 container. Ad esempio, un documento può contenere una serie di paragrafi. Un paragrafo può contenere testo, immagini, link e decorazioni di testo. Ogni elemento nella struttura ad albero degli oggetti può avere proprietà, ad esempio ruolo (che cos'è?), un nome o un'etichetta, un valore inserito dall'utente, una descrizione e stati booleani come attivabile, attivo, obbligatorio o 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à buffer virtuale, ad esempio "vai all'intestazione successiva".
• Una serie di eventi che si verificano che descrivono i cambiamenti nell'albero, ad esempio "l'elemento attivo è qui sopra!". 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.