Attributi ARIA: cosa sono, quando usarli e errori da evitare

Il 9 dicembre 2021 una grande novità è comparsa sul mondo dell’accessibilità: lo standard ARIA in HTML. La fonte è ovviamente il W3C (World Wide Web Consortium), nell’ambito della Web Accessibility Initiative, ossia il progetto volto a rendere il mondo del web più accessibile e inclusivo per tutti quanti. Se hai un sito web e vuoi rispettare gli standard sull’accessibilità (cosa che dovresti fare o rischi delle sanzioni), leggi questo articolo per scoprire cos’è ARIA in HTML, il nuovo standard per l’accessibilità web.

Cos’è ARIA in HTML

ARIA sta per Accessible Rich Internet Applications ed è una specifica del W3C, nell'ambito della Web Accessibility Initiative (WAI). Non è un linguaggio di programmazione, ma un insieme di attributi che si aggiungono al markup HTML per comunicare ruolo, stato e proprietà di un elemento alle tecnologie assistive, attraverso quello che si chiama albero di accessibilità.

Ruoli, proprietà e stati degli attributi ARIA

Gli attributi ARIA si dividono in tre famiglie, ciascuna con un compito diverso.

I ruoli definiscono cosa è o cosa fa un elemento. role="button" dice alla tecnologia assistiva che quell'elemento si comporta come un pulsante, anche se sotto il cofano è un semplice <div>.

html

<div role="button">Elimina</div>

Le proprietà descrivono caratteristiche che restano stabili nel tempo, come una relazione tra due elementi. aria-describedby collega un elemento alla sua descrizione estesa, mentre aria-required segnala che un campo di un modulo è obbligatorio.

Gli stati cambiano in base a un'interazione dell'utente o a un evento. aria-expanded="true" indica che un menu a tendina è aperto in quel momento; un istante dopo, un clic può riportarlo a false.

La distinzione tra proprietà e stati è tecnica e ha poco peso pratico per chi scrive contenuti o codice ogni giorno: nella maggior parte delle guide, entrambi vengono chiamati semplicemente attributi ARIA.

aria-label, aria-labelledby e aria-describedby: quale usare

Tra tutti gli attributi ARIA, quelli della famiglia dei nomi accessibili sono i più cercati e anche i più fraintesi. Servono tutti a dare un nome all'elemento che la tecnologia assistiva annuncia, ma si comportano in modo diverso.

aria-label assegna un'etichetta testuale che esiste solo per la tecnologia assistiva e non compare a schermo. È la scelta giusta quando un elemento non ha un testo visibile da riutilizzare, come un'icona cliccabile.

<button aria-label="Chiudi la finestra">✕</button>

aria-labelledby punta invece all'ID di un altro elemento già presente nella pagina, e usa il suo testo come etichetta. Ha la precedenza più alta nel calcolo del nome accessibile: se un elemento ha entrambi gli attributi, il browser ignora aria-label e usa aria-labelledby. È preferibile ogni volta che un testo visibile e pertinente esiste già nel DOM, perché evita di duplicare contenuto e riduce il rischio di incoerenza tra ciò che si vede e ciò che si sente.

<h2 id="titolo-sezione">Preferenze account</h2>
<section aria-labelledby="titolo-sezione">…</section>

aria-describedby non sostituisce il nome dell'elemento, ma aggiunge una descrizione più estesa, come un suggerimento sul formato richiesto per un campo di un modulo. Quando serve solo un'etichetta breve, meglio aria-label o aria-labelledby; quando serve un contesto più lungo, aria-describedby è lo strumento adatto.

aria-label e aria-live: gli attributi che gestiscono i contenuti dinamici

aria-label e aria-live risolvono due problemi diversi, anche se capita di trovarli confusi tra loro:

• Il primo dà un nome a un elemento statico;

• il secondo dice alla tecnologia assistiva se e come annunciare un contenuto che cambia da solo, senza che l'utente abbia cliccato o spostato il focus.

aria-live accetta tre valori:

• off non annuncia nulla, ed è il comportamento predefinito.

• polite aspetta che lo screen reader finisca di leggere quello che stava leggendo, poi annuncia l'aggiornamento: è la scelta giusta per un messaggio di conferma dopo l'invio di un modulo.

• assertive interrompe la lettura in corso per annunciare subito, e va riservato a messaggi davvero urgenti, come un errore che blocca il completamento di un'operazione

<div aria-live="polite">Messaggio inviato correttamente.</div>

Una regione live va inserita nel DOM prima che il contenuto cambi, non creata al volo insieme al messaggio: alcuni screen reader non rilevano un elemento aria-live se compare nella pagina nello stesso istante in cui già contiene il testo da annunciare.

I landmark roles: le zone della pagina

Tra i ruoli ARIA, i landmark roles hanno un compito specifico: segnalare le grandi aree di una pagina, così che chi usa uno screen reader possa saltare direttamente al contenuto principale invece di attraversare tutto il menu ogni volta. banner identifica l'intestazione del sito, navigation il blocco dei link di navigazione, main il contenuto centrale, contentinfo il footer.

La maggior parte degli elementi HTML5 porta già un landmark implicito: <nav> equivale a role="navigation", <main> a role="main", <footer> a role="contentinfo". Il landmark ARIA torna utile quando serve distinguere due elementi con lo stesso ruolo, come due <nav> diverse nella stessa pagina.

html

<nav aria-label="Menu principale">…</nav>
<nav aria-label="Link utili nel footer">…</nav>

Senza quella distinzione, uno screen reader annuncerebbe due volte "navigazione" senza altro contesto, lasciando all'utente il compito di capire quale delle due sia quella che cerca.

Le cinque regole per usare ARIA

Il primo istinto di chi scopre gli attributi ARIA è aggiungerli ovunque per sicurezza. È l'errore più comune: uno studio annuale sull'accessibilità dei siti web, il WebAIM Million, ha rilevato più volte che le home page con ARIA presentano in media più errori rilevati rispetto a quelle che non lo usano, quasi sempre per un'implementazione scorretta. Il gruppo WAI ha quindi definito cinque regole di base.

1. Usare prima l'elemento HTML nativo, se esiste già con la semantica e il comportamento richiesti (un <button> invece di un <div role="button">)

2. Non alterare la semantica di un elemento HTML che già funziona bene, evitando ruoli che confliggono con il tag scelto

3. Garantire sempre la navigazione da tastiera su ogni elemento interattivo creato con ARIA, con tabindex="0" dove serve

Questa terza regola vale un chiarimento in più, perché passa quasi sempre da tabindex. Un <div> con role="button" non riceve il focus da tastiera per impostazione predefinita: serve aggiungere tabindex="0" per inserirlo nell'ordine di tabulazione naturale della pagina.

tabindex="-1" toglie invece l'elemento dall'ordine di tabulazione, ma lo lascia raggiungibile via script, utile per esempio su un titolo a cui spostare il focus dopo un cambio di pagina in una single page application. Un valore positivo, come tabindex="3", andrebbe evitato quasi sempre: impone un ordine manuale che ignora la struttura visiva della pagina e diventa difficile da mantenere.

<div role="button" tabindex="0">Conferma</div>

Le altre due regole meritano un paragrafo a parte, perché riguardano errori che si vedono spesso in produzione.

1. Non aggiungere aria-hidden="true" o role="presentation" a un elemento che deve restare attivabile, perché la tecnologia assistiva lo salterà del tutto, come se non esistesse.

2. Ogni elemento interattivo deve avere un nome accessibile, che può arrivare dal contenuto testuale, da un'etichetta collegata o, quando nulla di tutto questo è disponibile, da aria-label.

Ruoli ridondanti e altri errori frequenti

Un errore diffuso è assegnare un ruolo ARIA a un elemento che ha già quella semantica in modo nativo. <ul role="list"> non aggiunge nulla: la lista non ordinata è già un elenco per qualsiasi tecnologia assistiva, e il ruolo extra è solo peso in più nel codice.

Un altro errore riguarda i ruoli assegnati a intestazioni o testo generico. <h2 role="tab">Scheda impostazioni</h2> confonde lo screen reader, che non sa più se trattare l'elemento come un'intestazione o come una scheda di navigazione. La soluzione è separare i due ruoli: l'intestazione resta un'intestazione, avvolta in un contenitore che porta il ruolo di scheda.

html

<div role="tab"><h2>Scheda impostazioni</h2></div>

Infine, i ruoli ARIA sovrascrivono il ruolo nativo dell'elemento su cui vengono applicati. Metterne uno sbagliato su un tag già semanticamente corretto, come role="heading" su un link, non aggiunge informazione: la sostituisce con un'informazione sbagliata.

Provare ARIA in pratica

Capire un attributo ARIA sulla carta e vederlo funzionare sono due cose diverse. La ARIA Authoring Practices Guide del W3C raccoglie pattern completi — tab, dialog, menu, accordion — con codice pronto ed esempi testabili direttamente nel browser: è il riferimento più solido per chi vuole passare dalla teoria a un componente reale.

Un secondo strumento, più immediato, è l'albero di accessibilità integrato nei DevTools di Chrome e Firefox. Con qualsiasi pagina aperta, basta ispezionare un elemento e passare al pannello Lighthouse "Accessibility" per vedere in tempo reale il nome, il ruolo e lo stato che la tecnologia assistiva riceverà, compreso l'effetto di un attributo ARIA appena aggiunto o rimosso.

Ecco la guida completa per Google Chrome

Perché il W3C ha rilasciato ARIA in HTML

L’HTML, pur essendo il linguaggio di markup più diffuso, non è particolarmente ricco di elementi semantici (ossia di tag HTML che indicano espressamente la loro funzione, come come <header>, <nav>, <main> o <table>). In tema di accessibilità, è una carenza non da poco, dato che gli screen reader traggono enorme giovamento dalla presenza di HTML semantici, avendo la possibilità di funzionare senza grandi quantità di codice lato user.

Per questa ragione, il W3C aveva rilasciato WAI-ARIA, che permette di integrare il markup HTML con ulteriori elementi semantici. In questo modo, però, eseguendo  l’implementazione di WAI-ARIA con poca attenzione ai ruoli nativi che HTML contiene, avvengono spesso conflitti fra i due linguaggi. Infatti, spesso si vanno ad aggiungere, o, ancora peggio, a sovrascrivere, i comportamenti predefiniti che sono fondamentali per la comprensione della struttura.

ARIA in HTML ha quindi l’obiettivo di rendere i due codici più “connettibili”, così da facilitare lo sviluppo nel nome dell’accessibilità.

Come rendere il tuo sito accessibile facilmente

Gli attributi ARIA restano uno strumento potente quando l'HTML nativo non basta, non un livello da aggiungere per abitudine. La regola più utile da portare con sé è la prima delle cinque: se un elemento HTML fa già il lavoro, non serve altro.

I nomi accessibili — aria-label, aria-labelledby, aria-describedby — sono il terreno dove si concentrano più errori e più ricerche, perché è lì che si decide se un utente capisce cosa sta per attivare. E un attributo ARIA scritto bene non si nota mai: funziona in silenzio, esattamente come dovrebbe.

Prima di aggiungere il prossimo attributo ARIA, un audit sui 4 principi dell'accessibilità web aiuta a capire se il problema è davvero di semantica o si risolve più a monte, nella struttura HTML.

Domande frequenti sugli attributi ARIA

Cosa sono gli attributi ARIA

Gli attributi ARIA sono specifiche del W3C che si aggiungono al codice HTML per comunicare ruolo, stato e proprietà di un elemento alle tecnologie assistive, come gli screen reader, senza modificarne l'aspetto visivo.

Qual è la differenza tra aria-label e aria-labelledby

aria-label assegna un testo che esiste solo per la tecnologia assistiva; aria-labelledby punta invece a un testo già visibile nella pagina e ha la precedenza quando entrambi sono presenti sullo stesso elemento.

Quando è meglio non usare ARIA

Sì, ci sono casi frequenti in cui ARIA va evitato: quando un elemento HTML nativo offre già la semantica e il comportamento richiesti, aggiungere un ruolo ARIA è ridondante e può creare conflitti.

Gli attributi ARIA influenzano il posizionamento SEO

No, gli attributi ARIA non sono un fattore diretto di ranking, ma migliorano l'esperienza per chi usa tecnologie assistive e riducono gli errori di accessibilità che possono penalizzare indirettamente l'esperienza complessiva del sito.

Gli attributi ARIA sono obbligatori per la conformità alle WCAG

No, non sono obbligatori in assoluto: le WCAG richiedono che ogni componente abbia un nome, un ruolo e un valore accessibili, e ARIA è uno dei metodi possibili per raggiungere quel risultato quando l'HTML nativo non basta.

Disclaimer: Contenuto generato con il supporto dell'intelligenza artificiale e sottoposto a supervisione e revisione umana