La maggior parte degli sviluppatori conosce il linguaggio di markup standard del nostro moderno Web, HyperText Markup Language (HTML). Tuttavia, potresti avere meno familiarità con Accessible Rich Internet Applications (ARIA) (precedentemente chiamato WAI-ARIA): cos'è, come vengono utilizzate e quando e quando non per utilizzarle.
HTML e ARIA svolgono un ruolo importante nel rendere accessibili i prodotti digitali, in particolare quando si tratta di tecnologie per la disabilità come gli screen reader. Entrambe vengono utilizzate per convertire i contenuti in un formato alternativo, come braille o Sintesi vocale (TTS).
Esaminiamo una breve storia di ARIA, perché è importante, quando e come utilizzarlo al meglio.
Introduzione ad ARIA
ARIA è stata sviluppata per la prima volta nel 2008 dal gruppo Web Accessibility Initiative (WAI), un sottoinsieme del World Wide Web Consortium (W3C), che governa e regola 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 ruolo, stato e proprietà alle tecnologie per la disabilità tramite le API di accessibilità disponibili nei browser moderni. Questa comunicazione avviene attraverso l'albero dell'accessibilità.
"WAI-ARIA, Accessible Rich Internet Applications Suite, definisce un modo per rendere i contenuti e le applicazioni web più accessibili alle persone con disabilità. È particolarmente utile per i contenuti dinamici e i controlli avanzati dell'interfaccia utente sviluppati con HTML, JavaScript e tecnologie correlate."
Il gruppo WAI
L'albero dell'accessibilità
ARIA modifica il codice errato o incompleto per creare un'esperienza migliore per chi utilizza AT cambiando, esponendo e incrementando parti della struttura dell'accessibilità.
La struttura ad albero dell'accessibilità viene creata dal browser e si basa sull'albero DOM (Document Object Model) standard. Come l'albero DOM, anche l'albero dell'accessibilità contiene oggetti che rappresentano tutti gli elementi di markup, gli attributi e i nodi di testo. L'albero dell'accessibilità viene utilizzato anche dalle API di accessibilità specifiche della piattaforma per fornire una rappresentazione comprensibile alle tecnologie per la disabilità.
Il feed ARIA da solo non modifica la funzionalità o l'aspetto visivo di un elemento. Ciò significa che solo gli utenti AT noteranno differenze tra un prodotto digitale con ARIA e uno senza. Ciò significa anche che i soli sviluppatori sono responsabili di apportare le modifiche appropriate al codice e agli stili per rendere un elemento il più accessibile possibile.
Le tre caratteristiche principali di ARIA sono i ruoli, le proprietà e gli stati/valori.
I ruoli definiscono l'attività o l'attività di un elemento nella pagina o nell'app.
<div role="button">Self-destruct</div>
Le proprietà esprimono caratteristiche o relazioni a 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/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 un'unica riga di codice, non è obbligatorio. Puoi invece sovrapporre i ruoli, le proprietà e gli stati/valori ARIA fino a quando non raggiungi l'obiettivo di accessibilità finale. La corretta integrazione di ARIA nel codebase garantisce che gli utenti AT dispongano di tutte le informazioni necessarie per utilizzare il sito web, l'app o un altro prodotto digitale in modo corretto ed equo.
Di recente, Chrome DevTools ha creato un modo per visualizzare l'intero albero dell'accessibilità, consentendo agli sviluppatori di comprendere più facilmente in che modo il codice influisce sull'accessibilità.
Quando utilizzare ARIA
Nel 2014, il W3C ha pubblicato ufficialmente la raccomandazione HTML5. Sono stati apportati alcuni grandi cambiamenti, 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, insieme a un maggiore supporto del browser, alcune parti di ARIA sono ora meno fondamentali.
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à che non sono disponibili in nessuna versione del codice HTML. Questi attributi rimangono utili per il momento.
Questo ci porta alla domanda finale: quando è opportuno 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 capito bene. L'aggiunta di ARIA a un elemento non lo rende intrinsecamente più accessibile. Il report annuale sull'accessibilità di WebAIM Million ha rilevato che le home page con ARIA presenti in media registrano il 70% di errori in più rilevati rispetto a quelle senza ARIA, principalmente a causa dell'implementazione non corretta degli attributi ARIA.
Esistono eccezioni a questa regola. ARIA è obbligatorio quando un elemento HTML non supporta l'accessibilità. Questo potrebbe dipendere dal fatto che il design non consente un elemento HTML specifico o che la funzionalità/il comportamento desiderata non è disponibile in HTML. Tuttavia, queste situazioni dovrebbero essere scarse.
<a role="button">Submit</a>
<button>Submit</button>
In caso di dubbi, utilizza elementi semantici HTML.
Regola 2: non aggiungere (non necessario) ARIA al codice HTML
Nella maggior parte dei casi, gli elementi HTML funzionano bene da subito e non richiedono l'aggiunta di ulteriori ARIA. Infatti, gli sviluppatori che utilizzano ARIA spesso devono aggiungere ulteriore codice per rendere funzionali gli elementi nel caso di elementi interattivi.
<h2 role="tab">Heading tab</h2>
<div role="tab"><h2>Heading tab</h2></div>
Svolgere meno lavoro e avere 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 dalla tastiera. Puoi aggiungere tabindex= "0" a qualsiasi elemento per cui è necessario impostare lo stato attivo che normalmente non riceve lo stato attivo della tastiera. Quando possibile, evita di utilizzare gli indici di tabulazione con numeri interi positivi per evitare potenziali problemi relativi all'ordine di impostazione delle priorità della tastiera.
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>Ovviamente, se puoi, utilizza un elemento
<button> reale in questo caso.
Regola 4: non nascondere gli elementi attivabili
Non aggiungere role= "presentation" o aria-hidden= "true" agli elementi che devono
essere impostati come attivo, inclusi gli elementi con tabindex= "0". Quando aggiungi questi ruoli/stati agli elementi, viene inviato all'AT un messaggio che informa che questi elementi non sono importanti e che li ignori. Questo può creare confusione o
interrompere gli utenti che tentano di interagire con un elemento.
<div aria-hidden="true"><button>Submit</button></div>
<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 l'elemento. Assicurati che tutti gli elementi abbiano un nome accessibile per le persone che utilizzano i dispositivi AT.
I nomi accessibili possono essere i contenuti racchiusi da un elemento (nel caso di <a>), da testo alternativo o da un'etichetta.
Per ciascuno dei seguenti esempi di codice, il nome accessibile è "Stivali di pelle rossi".
<!-- 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 verificare il nome accessibile di un elemento, tra cui l'ispezione dell'albero dell'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 nei pattern che richiedono un livello più elevato di supporto AT a causa di vincoli ambientali o come metodo di riserva per gli elementi HTML che non sono completamente supportati da tutti i browser.
Naturalmente, esistono suggerimenti per l'implementazione di ARIA in HTML. Soprattutto: non sostituire i ruoli HTML predefiniti, ridurre la ridondanza e prestare attenzione agli effetti collaterali indesiderati.
Vediamo alcuni esempi.
<a role="heading">Read more</a>Ruolo errato assegnato.
<a aria-label="Read more about some awesome article title">Read More</a>Ruolo corretto e una descrizione aggiuntiva del link.
<ul role="list">...</ul>Ruolo ridondante.
<ul>...</ul>Ridondanza rimossa
<details> <summary role="button">more information</summary> ... </details>Potenziali effetti collaterali.
<details> <summary>more information</summary> ... </details>Nessun effetto collaterale indesiderato.
Complessità di ARIA
ARIA è un servizio complesso, pertanto devi sempre prestare attenzione quando lo utilizzi. Sebbene gli esempi di codice in questa lezione siano piuttosto semplici, creare pattern personalizzati accessibili può diventare rapidamente complicato.
Ci sono molti aspetti a cui prestare attenzione, inclusi, a titolo esemplificativo: interazioni da tastiera, interfacce touch, supporto AT/browser, esigenze di traduzione, vincoli ambientali, codice precedente e preferenze utente. Un po' di conoscenza della programmazione può essere dannosa o semplicemente fastidiosa se utilizzata in modo scorretto. Ricorda di utilizzare un codice semplice.
A parte questi avvisi, l'accessibilità digitale non è una situazione tutto o niente, ma uno spettro che consente alcune aree grigie come questa. Più soluzioni di codifica possono essere considerate "corrette", a seconda della situazione. ma è importante continuare a imparare, testare e cercare di rendere il nostro mondo digitale più aperto a tutti.
Verifica la tua comprensione
Verifica le tue conoscenze di ARIA e HTML
Quale delle seguenti è la best practice per creare un pulsante accessibile?
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div><a id="saveChanges" aria-label="Some awesome article title">Go to shop</a><button id="saveChanges" type="button">Go to shop</button>