La maggior parte degli sviluppatori conosce il linguaggio di markup standard del web moderno, il linguaggio di markup degli ipertesti (HTML). Tuttavia, potresti avere meno familiarità con Applicazioni Internet Avanzate Accessibili (ARIA) (formalmente chiamate WAI-ARIA): che cos'è, come viene utilizzata e quando e quando nonutilizzarla.
HTML e ARIA svolgono un ruolo importante nel rendere accessibili i prodotti digitali, soprattutto quando si tratta di tecnologie per la disabilità (AT) come gli screen reader. Entrambi vengono utilizzati per convertire i contenuti in un formato alternativo, come Braille o Text-to-Speech (TTS).
Esamina una breve storia di ARIA, perché è importante e quando e come utilizzarla al meglio.
Introduzione ad ARIA
ARIA è stato sviluppato per la prima volta nel 2008 dal gruppo Web Accessibility Initiative (WAI), un sottoinsieme del World Wide Web Consortium (W3C), che governa e regolamenta internet.
ARIA non è un vero linguaggio di programmazione, ma un insieme di attributi che puoi aggiungere agli elementi HTML per aumentarne l'accessibilità. Questi attributi comunicano il ruolo, lo stato e la proprietà alle tecnologie assistive utilizzando le API di accessibilità presenti nei browser moderni. Questa comunicazione avviene tramite l'albero di accessibilità.
"WAI-ARIA, la suite di applicazioni internet avanzate accessibili, definisce un modo per rendere i contenuti web e le applicazioni web più accessibili alle persone con disabilità. Aiuta in particolare con i contenuti dinamici e i controlli dell'interfaccia utente avanzati sviluppati con HTML, JavaScript e tecnologie correlate."
Il gruppo WAI
L'albero di accessibilità
ARIA modifica il codice errato o incompleto per creare un'esperienza migliore per chi utilizza AT modificando, esponendo e aumentando le parti dell'albero di accessibilità.
L'albero di accessibilità viene creato dal browser e si basa sull'albero DOM (Document Object Model) standard. Come l'albero DOM, l'albero di accessibilità contiene oggetti che rappresentano tutti gli elementi di markup, gli attributi e i nodi di testo. L'albero di accessibilità viene utilizzato anche dalle API di accessibilità specifiche della piattaforma per fornire una rappresentazione che le tecnologie assistive possono comprendere.
ARIA da solo non modifica la funzionalità o l'aspetto visivo di un elemento. Ciò significa che solo gli utenti AT noteranno le differenze tra un prodotto digitale con ARIA e uno senza. Ciò significa anche che solo gli sviluppatori sono responsabili delle modifiche appropriate al codice e allo stile per rendere un elemento il più accessibile possibile.
Le tre funzionalità principali di ARIA sono ruoli, proprietà e stati/valori.
I ruoli definiscono cosa è o cosa fa un elemento nella pagina o nell'app.
<div role="button">Self-destruct</div>
Le proprietà esprimono caratteristiche o relazioni con un oggetto.
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
Gli stati e i valori definiscono le condizioni attuali o i valori dei dati associati all'elemento.
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
Sebbene tutti e tre gli elementi di ARIA possano essere utilizzati in una riga di codice, non è obbligatorio. Invece, sovrapponi ruoli, proprietà e stati o valori ARIA finché non hai raggiunto l'obiettivo di accessibilità finale. L'incorporamento corretto di ARIA nella base di codice garantisce che gli utenti AT dispongano di tutte le informazioni necessarie per utilizzare il tuo sito web, la tua app o un altro prodotto digitale in modo efficace ed equo.
Di recente, Chrome DevTools ha creato un modo per visualizzare l'intero albero di accessibilità consentendo agli sviluppatori di comprendere più facilmente l'impatto del codice sull' accessibilità.
Quando utilizzare ARIA
Nel 2014, il W3C ha pubblicato ufficialmente la raccomandazione HTML5. Con essa sono state apportate
alcune modifiche importanti, tra cui l'aggiunta di elementi di riferimento come <main>,
<header>, <footer>, <aside>, <nav>, e attributi come hidden e
required. Con questi nuovi elementi e attributi HTML5, uniti al maggiore supporto dei browser, alcune parti di ARIA sono ora meno importanti.
Quando il browser supporta un tag HTML con un ruolo implicito con un equivalente ARIA, in genere non è necessario aggiungere ARIA all'elemento. Tuttavia, ARIA include ancora molti ruoli, stati e proprietà non disponibili in nessuna versione di HTML. Questi attributi rimangono utili per il momento.
Questo ci porta alla domanda finale: quando dovresti utilizzare ARIA? Fortunatamente il gruppo WAI ha sviluppato le cinque regole di ARIA per aiutarti a decidere come rendere accessibili gli elementi.
Regola 1: non utilizzare ARIA
Sì, hai letto bene. L'aggiunta di ARIA a un elemento non lo rende intrinsecamente più accessibile. Il report annuale sull'accessibilità WebAIM Million ha rilevato che le home page con ARIA presentavano in media il 70% in più di errori rilevati rispetto a quelle senza ARIA, principalmente a causa dell'implementazione errata degli attributi ARIA.
Esistono eccezioni a questa regola. ARIA è obbligatorio quando un elemento HTML non supporta l'accessibilità. Questo potrebbe essere dovuto al fatto che il design non consente un elemento HTML specifico o che la funzionalità o il comportamento desiderati non sono disponibili in HTML. Tuttavia, queste situazioni dovrebbero essere rare.
Non: assegnare un ruolo.
<a role="button">Submit</a>
Esegui: utilizza l'elemento semantico.
<button>Submit</button>
In caso di dubbi, utilizza gli elementi HTML semantici.
Regola 2: non aggiungere ARIA (non necessario) a HTML
Nella maggior parte dei casi, gli elementi HTML funzionano bene così come sono e non è necessario aggiungere ARIA. Infatti, gli sviluppatori che utilizzano ARIA spesso devono aggiungere codice aggiuntivo per rendere funzionali gli elementi nel caso di elementi interattivi.
Non: assegnare un ruolo fuorviante.
<h2 role="tab">Heading tab</h2>
Esegui: assegna i ruoli correttamente.
<div role="tab"><h2>Heading tab</h2></div>
Lavora di meno e ottieni un codice con prestazioni migliori quando utilizzi gli elementi HTML come previsto.
Regola 3: supporta sempre la navigazione da tastiera
Tutti i controlli ARIA interattivi (non disattivati) devono essere accessibili da tastiera. Puoi aggiungere tabindex= "0" a qualsiasi elemento che necessita di un focus che normalmente non riceve il focus della tastiera. Evita di utilizzare gli indici di tabulazione con numeri interi positivi , se possibile, per evitare potenziali problemi di ordine del focus della tastiera.
Non: aggiungere un tabindex.
<span role="button" tabindex="1">Submit</span>
Esegui: imposta il tabindex su `0`.
<span role="button" tabindex="0">Submit</span>
Naturalmente, se puoi, utilizza un vero elemento <button> in questo caso.
Regola 4: non nascondere gli elementi focalizzabili
Non aggiungere role= "presentation" o aria-hidden= "true" agli elementi che devono
avere il focus, inclusi gli elementi con tabindex= "0". Quando aggiungi questi ruoli e stati agli elementi, invii un messaggio ad AT che indica che questi elementi non sono importanti e che devono essere ignorati. Ciò può causare confusione o interrompere gli utenti che tentano di interagire con un elemento.
Non: nascondere gli elementi focalizzabili
<div aria-hidden="true"> <button>Submit</button> </div>
Esegui: esponi gli elementi selezionabili
<div> <button>Submit</button> </div>
Regola 5: utilizza nomi accessibili per gli elementi interattivi
Lo scopo di un elemento interattivo deve essere comunicato a un utente prima che sappia come interagire con esso. Assicurati che tutti gli elementi abbiano un nome accessibile per le persone che utilizzano dispositivi AT.
I nomi accessibili possono essere i contenuti racchiusi da un elemento (nel caso di un
<a>), il testo alternativo o un'etichetta.
Per ognuno dei seguenti esempi di codice, il nome accessibile è "Stivali in pelle rossa".
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
Esistono molti modi per controllare il nome accessibile di un elemento, tra cui l'ispezione dell'albero di accessibilità utilizzando Chrome DevTools o il test con uno screen reader.
ARIA in HTML
Sebbene l'utilizzo degli elementi HTML da soli sia una best practice, gli elementi ARIA possono essere aggiunti in determinate situazioni. Ad esempio, puoi accoppiare ARIA con HTML in pattern che richiedono un livello di supporto AT più elevato a causa di vincoli ambientali o come metodo di fallback per gli elementi HTML non completamente supportati da tutti i browser.
Naturalmente, esistono raccomandazioni per l'implementazione di ARIA in HTML. Ancora più importante: non sostituire i ruoli HTML predefiniti, ridurre la ridondanza e tenere conto degli effetti collaterali non intenzionali.
Dai un'occhiata ad alcuni esempi.
Non: assegnare il ruolo sbagliato.
<a role="heading">Read more</a>
Esegui: utilizza il ruolo corretto e una descrizione del link aggiuntiva.
<a aria-label="Read more about some awesome article title">Read More</a>
Non: aggiungere un ruolo ridondante.
<ul role="list">...</ul>
Esegui: riduci la ridondanza.
<ul>...</ul>
Non: perdere potenziali effetti collaterali.
<details> <summary role="button">more information</summary> ... </details>
Esegui: risolvi gli effetti collaterali.
<details> <summary>more information</summary> ... </details>
Complessità di ARIA
ARIA è complesso e dovresti sempre utilizzarlo con cautela. Sebbene gli esempi di codice in questa lezione siano abbastanza semplici, la creazione di pattern personalizzati accessibili può diventare rapidamente complicata.
Ci sono molte cose a cui prestare attenzione, tra cui, a titolo esemplificativo: interazioni da tastiera, interfacce touch, supporto AT/browser, esigenze di traduzione, vincoli ambientali, codice legacy e preferenze utente. Una piccola conoscenza della programmazione può essere dannosa o semplicemente fastidiosa se utilizzata in modo errato.
A parte questi avvisi, l'accessibilità digitale non è una situazione di tutto o niente, ma uno spettro che consente alcune aree grigie come questa. A seconda della situazione, più soluzioni di codifica possono essere considerate "corrette". Ciò che conta è continuare a imparare, testare e cercare di rendere il nostro mondo digitale più aperto a tutti.