Cosa sono gli attributi ARIA? WAI-ARIA spiegato in modo semplice

ARIA sta per Accessible Rich Internet Applications. È un insieme di attributi HTML, standardizzato dal W3C con il nome WAI-ARIA (versione attuale 1.2, pubblicata nel giugno 2023), che fornisce alle tecnologie assistive come gli screen reader informazioni aggiuntive sugli elementi dell'interfaccia. ARIA diventa necessario dove finisce la semantica dell'HTML nativo: un'interfaccia a schede, un accordion, un menu a tendina personalizzato o un messaggio di stato che compare dinamicamente. Il vocabolario si compone di tre mattoni: i ruoli descrivono cos'è un elemento, gli stati ne descrivono la condizione attuale e le proprietà ne descrivono caratteristiche e relazioni. ARIA è potente e pericoloso allo stesso tempo. Usato correttamente rende utilizzabili widget complessi per chi naviga con uno screen reader, usato male distrugge attivamente l'accessibilità, ed è il motivo per cui la regola più importante di ARIA è preferire gli elementi HTML nativi ogni volta che sono in grado di fare il lavoro.

Cosa significa ARIA e perché esiste?

L'HTML ha una semantica integrata ricca: un button viene annunciato come pulsante, un nav è una navigazione, una casella di spunta selezionata comunica da sola il proprio stato. Gli screen reader leggono tutto questo dall'albero di accessibilità che il browser costruisce a partire dal tuo markup. Il problema comincia con tutto ciò per cui l'HTML non ha un elemento. Non esiste un pannello a schede nativo, né un accordion, né una notifica toast. Gli sviluppatori li costruiscono con div e span, e per chi usa uno screen reader un accordion fatto di div è solo silenzio: nessun nome, nessun ruolo, nessuno stato.

WAI-ARIA colma esattamente questa lacuna. Ti permette di comunicare alla tecnologia assistiva cos'è il tuo widget personalizzato e cosa sta facendo, senza cambiare nulla nell'aspetto o nel comportamento della pagina per tutti gli altri.

Ruoli, stati e proprietà: i tre mattoni di ARIA

• I ruoli definiscono cos'è un elemento. role="dialog", role="tablist", role="alert". Un ruolo è una promessa fatta all'utente: questa cosa si comporterà come una finestra di dialogo.
• Gli stati descrivono la condizione attuale e mutevole di un elemento. aria-expanded="true", aria-checked="false", aria-disabled="true". Gli stati cambiano mentre l'utente interagisce e il tuo JavaScript deve tenerli allineati.
• Le proprietà descrivono caratteristiche e relazioni che cambiano di rado. aria-labelledby rimanda all'elemento che dà il nome a questo, aria-controls rimanda all'elemento che questo comanda, aria-required segnala un campo obbligatorio.

La distinzione tra stati e proprietà è accademica nel lavoro quotidiano, sono comunque entrambi semplici attributi. Il modello mentale che conta è questo: il ruolo dice cos'è, tutto il resto dice come si chiama, cosa sta facendo e a cosa appartiene.

La prima regola di ARIA: non usare ARIA

Il documento del W3C Using ARIA si apre con una regola che sembra una battuta ma è del tutto seria: se esiste già un elemento HTML nativo con la semantica e il comportamento che ti servono, usalo invece di riadattare un altro elemento aggiungendoci ARIA. Confronta questi due modi di costruire un pulsante:

<!-- Sembra un pulsante a chi vede, è un div morto per tutti gli altri -->
<div class="btn" onclick="save()">Salva</div>

<!-- Tutto incluso: ruolo, supporto da tastiera, focus -->
<button type="button" onclick="save()">Salva</button>

Per sistemare la versione con il div ti servirebbero role="button", tabindex="0" e altro JavaScript per i tasti Invio e Spazio. L'elemento nativo fa tutto questo gratuitamente e continuerà a farlo in browser che non hai mai testato. La stessa logica vale per link, caselle di spunta, campi di modulo e titoli.

Dietro questa regola c'è un dato che fa riflettere. WebAIM analizza ogni anno il milione di home page più visitate e i suoi report rilevano con costanza che le pagine che usano ARIA presentano in media più errori di accessibilità di quelle che non lo usano. Non perché ARIA sia sbagliato, ma perché viene applicato male molto di frequente. Nessun ARIA è meglio di un ARIA rotto.

Gli attributi ARIA più importanti spiegati

• aria-label: assegna direttamente a un elemento il suo nome accessibile. Il caso d'uso classico è un pulsante con la sola icona: aria-label="Chiudi" sulla X di una finestra modale.
• aria-labelledby: rimanda all'ID di un altro elemento, il cui testo visibile diventa il nome. Da preferire ad aria-label quando esiste un'etichetta visibile, perché i due non possono divergere.
• aria-describedby: rimanda a un testo descrittivo aggiuntivo, di solito un suggerimento o un messaggio di errore sotto un campo di modulo.
• aria-hidden="true": rimuove un elemento e i suoi figli dall'albero di accessibilità. Giusto per le icone decorative, pericoloso su qualsiasi cosa possa ricevere il focus.
• aria-expanded: segnala sul comando se l'area controllata è aperta o chiusa. È la spina dorsale di accordion, menu a tendina e navigazione mobile.
• aria-controls: collega un comando all'elemento su cui agisce.
• aria-live: trasforma un elemento in una live region le cui variazioni di contenuto vengono annunciate automaticamente. polite attende una pausa, assertive interrompe subito e andrebbe riservato ai messaggi davvero urgenti.
• aria-current: segnala l'elemento corrente all'interno di un insieme, per esempio aria-current="page" sul link di navigazione attivo.
• aria-required e aria-invalid: comunicano nei moduli i campi obbligatori e gli errori di validazione. Con la validazione HTML nativa, il solo required copre già la prima parte.

Cosa sono i landmark role di ARIA?

I landmark suddividono una pagina in aree denominate tra cui chi usa uno screen reader può saltare direttamente, allo stesso modo in cui chi vede scorre visivamente un layout. La buona notizia: gli elementi HTML moderni creano la maggior parte dei landmark in modo implicito, quindi in un documento ben strutturato raramente scriverai questi ruoli a mano.

• header corrisponde al landmark banner
• nav corrisponde a navigation
• main corrisponde a main, e ne dovrebbe esistere esattamente uno per pagina
• aside corrisponde a complementary
• footer corrisponde a contentinfo
• form e section diventano landmark form e region quando hanno un nome accessibile

Un'abitudine che vale la pena adottare: se una pagina ha due navigazioni, distinguile con aria-label="Menu principale" e aria-label="Menu del footer". Sentirsi annunciare due volte navigazione senza alcuna distinzione non aiuta nessuno.

Esempi pratici di ARIA: accordion e live region

L'intestazione minima di un accordion accessibile mostra come si incastrano i pezzi. Il pulsante porta lo stato, il pannello viene richiamato tramite ID e JavaScript ribalta entrambi al clic:

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Spedizione e resi
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>Spediamo entro 2-4 giorni lavorativi...</p>
</div>

E una live region per il feedback che compare senza ricaricare la pagina, per esempio dopo un'aggiunta al carrello o una ricerca filtrata:

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = '12 prodotti trovati'
</script>

Senza la live region, chi usa uno screen reader filtra un elenco di prodotti e non sente proprio nulla. Con essa, il numero di risultati viene annunciato nel momento stesso in cui cambia. Attributo piccolo, differenza enorme.

Errori ARIA frequenti da evitare

• aria-hidden="true" su elementi che ricevono il focus: l'elemento sparisce dall'albero di accessibilità ma resta nell'ordine di tabulazione. Chi naviga da tastiera atterra su un fantasma. È uno degli errori ARIA più frequenti là fuori.
• Ruoli ridondanti: role="button" su un button o role="navigation" su un nav aggiunge rumore e mostra che il markup non è stato capito.
• Ruoli senza comportamento: role="tab" promette la navigazione con i tasti freccia. Se il tuo JavaScript non la fornisce, il ruolo peggiora le cose rispetto all'assenza di ruolo, perché crea aspettative che il widget non può soddisfare.
• Stati non aggiornati: un aria-expanded che resta false per sempre perché nessuno lo aggiorna nel gestore del clic. Chi usa uno screen reader sente chiuso mentre fissa un pannello aperto.
• aria-label su elementi di solo testo: su un div o uno span senza ruolo, aria-label viene ignorato dalla maggior parte delle tecnologie assistive. Non è un tooltip buono per tutti gli usi.
• Abuso delle live region assertive: se ogni aggiornamento del carrello, avviso sui cookie e riquadro della newsletter interrompe l'utente, gli annunci davvero importanti annegano.

ARIA nei temi e nei plugin WordPress

Il core di WordPress se la cava discretamente: il blocco di navigazione gestisce aria-expanded sui comandi dei sottomenu, la classe CSS screen-reader-text per le etichette nascoste visivamente è una convenzione consolidata e i componenti di modulo del core arrivano con attributi sensati. I guai di solito arrivano con ciò che viene installato sopra. Page builder, plugin per slider, mega menu e strumenti per i popup sono i luoghi in cui si accumula la zuppa di div con ARIA assente o rotto. Quando valuti un tema, il tag accessibility-ready nella directory dei temi di WordPress è un segnale genuino, perché quei temi passano una revisione rispetto a criteri definiti. Per tutto il resto, l'ARIA Authoring Practices Guide documenta schemi collaudati per quasi ogni widget che ti capiterà di costruire, comportamento da tastiera funzionante incluso.

Come verifica InspectWP l'uso di ARIA?

InspectWP esamina le tue pagine renderizzate nell'ambito dell'analisi di accessibilità e segnala i problemi legati ad ARIA che gli strumenti automatici sanno rilevare in modo affidabile: nomi di ruolo non validi, attributi ARIA non ammessi sull'elemento su cui si trovano, riferimenti a ID inesistenti, elementi che ricevono il focus ma sono nascosti con aria-hidden ed elementi interattivi senza nome accessibile. I risultati sono raggruppati per gravità, così un nome rotto sulla navigazione principale pesa più di un ruolo ridondante nel footer. Poiché a decidere cosa funziona è in ultima analisi il comportamento dello screen reader, considera il report come la tua prima passata, rapida e ripetibile, e verifica poi i percorsi critici con uno screen reader vero.