Ruoli e attributi ARIA: le migliori scelte a confronto
I Ruoli e attributi ARIA della specifica WAI-ARIA 1.2 del W3C superano il centenario, anche se un pugno risolve la maggior parte dei problemi di accessibilità nei widget XHTML e CSS. Un ruolo definisce cosa è un elemento e un attributo del suo stato o delle sue relazioni, ma ARIA non modifica il comportamento del browser: ciascun ruolo aggiunto richiede l’implementazione dell’interazione con JavaScript.
Accessible Rich Internet Applications (ARIA) è una specifica W3C che aggiunge semantica agli elementi HTML che non li hanno in una forma nativa. Un ruolo descrive cosa è un elemento (un button, una tab, un dialog), mentre un attributo descrive il suo stato o le sue relazioni (aria-expanded, aria-controls, aria-labelledby). La prima regola di ARIA, pubblicata dal W3C in Using ARIA, è schietta: se c’è un elemento HTML nativo che fa già il lavoro, usalo e non aggiungere ARIA.
Il motivo è che ARIA non modifica il comportamento del browser. Un <div role="button"> non riceve il focus con Tab, non risponde al tasto Invio o allo spazio e non viene inviato con un modulo.
Cambia solo ciò che annuncia la tecnologia assistiva. Tutte le interazioni devono essere implementate con JavaScript e gestite con attenzione. Nei progetti XHTML/CSS in cui l’HTML è statico e il JS è minimo, ciò significa che ciascuno dei ruoli e degli attributi dell’aria aggiunti è una promessa che il codice deve mantenere.
La seconda regola di ARIA chiede di non modificare la semantica nativa a meno che non sia imprescindibile. Un <h2 role="tab"> rompe la struttura dei titoli e confonde gli screen reader che navigano per regioni. La terza regola richiede che tutti i controlli ARIA siano utilizzabili tramite tastiera. Il quarto chiede di non utilizzare aria-hidden="true" sugli elementi che ricevono il focus. Il quinto, e il più dimenticato, ci ricorda che qualsiasi elemento interattivo richiede un nome accessibile: un ruolo senza etichetta è un pulsante muto.
Come scegliere: criteri prima dell’elenco
La scelta di un ruolo o di un attributo non è una questione di gusti. Questi criteri, applicati in ordine, evitano la maggior parte degli errori riguardanti i ruoli e gli attributi dell’aria:
Correlato: — Widget di accessibilità con piano gratuito per empezar hoy mismo.
- Esiste un elemento HTML nativo? Se sì, utilizzalo.
<button>,<details>,<dialog>,<input type="checkbox">coprono più casi di quanto si pensi. - Il widget necessita di stati dinamici? Se cambia tra aperto/chiuso, selezionato/non selezionato o espanso/compresso, sono necessari gli attributi di stato (
aria-expanded,aria-selected,aria-pressed). - Ha bisogno di relazioni tra elementi? Gli attributi di relazione (
aria-controls,aria-labelledby,aria-descriptionby,aria-owns) connettono pezzi che l’albero di accessibilità non può dedurre dal DOM. - Sono necessari annunci live? Le regioni live (
aria-live,role="status",role="alert") risolvono gli aggiornamenti senza spostare il focus. - Posso mantenerlo? Un pattern ARIA complesso senza test con tastiera o screen reader è peggio che non avere nulla.
Il costo di manutenzione è il criterio più ignorato. Un role="tablist" ben realizzato richiede la gestione dei tasti freccia, la rotazione di tabindex, la sincronizzazione di aria-selected e aria-controls e il corretto occultamento dei pannelli inattivi. Se il team non è in grado di gestirlo, una serie di collegamenti con ancore è più accessibile ed economica.
Comparativa dei ruoli ARIA più utili
La tabella successiva riprende i ruoli che appaiono ripetutamente in audit reali, con il suo equivalente nativo quando esiste e la trampa più abituale.
| Rol | Para qué sirve | Alternativa nativa | Trampa frequente |
|---|---|---|---|
| ”pulsante” | Controlla l’esecuzione di un’azione | <pulsante> | Non aggiungere il comando Enter/Espacio a tabindex="0" |
| ”collegamento” | Navigazione in un altro URL | <a href> | Usalo per azioni che non navighi |
dialogo | Ventana modale o non modale | <dialogo> | No atrapar el foco ni devolverlo al cerrar |
tablist / tab / tabpanel | Interfaccia peste | Ninguna diretta | Non sarà possibile sincronizzare aria-selected con il pannello visibile |
menu / menuitem | Menu dell’applicazione | <select> o elenco di collegamenti | Usalo per i menu di navigazione web |
| ”avviso” | Messaggio urgente e immediato | role="status" per non urgente | Abusar de él y saturar al lector de pantalla |
stato | Aggiornamento informativa | <output> | Non inserirlo nel DOM prima dell’aggiornamento |
barra di avanzamento | Progresso di una tara | <avanzamento> | Non aggiornare aria-valuenow |
descrizione comando | Descrizione emergente | titolo (limitato) | Non associarlo con aria-descriptionby |
combobox | Campo con elenco di suggerimenti | <datalist> (limitato) | Non annunciare il numero dei risultati |
La scelta tra role="alert" e role="status" è un buon esempio di una decisione con sfumature riguardanti i ruoli e gli attributi dell’aria. “alert” interrompe la lettura corrente dello screen reader; “status” attende che l’utente finisca. Per un errore di convalida del modulo, alert è appropriato. Per “3 risultati trovati” mentre l’utente scrive, status è corretto e alert risulta invadente.
Vale la pena dare un'occhiata: — Accessibilità gestionale: automatizzazione combinata con revisione umana.
Gli attributi ARIA sono imprescindibili e come si combinano
Gli attributi sono associati a quattro famiglie e ognuna risolve un problema distinto.
Etichettatura. aria-label fornisce un nome quando non è presente testo visibile. “aria-labelledby” fa riferimento all‘“id” di un altro elemento ed è preferibile quando il testo esiste già sullo schermo, perché mantiene un’unica fonte di verità. “aria-descriptionby” aggiunge una descrizione più lunga, come il testo di aiuto di un campo. La differenza è importante: il nome è ciò che l’utente sente durante la messa a fuoco; la descrizione è un contesto aggiuntivo che può essere interrotto.
Stati. aria-expanded (vero/falso) per fisarmoniche e menu a discesa. “aria-selected” per schede e opzioni. “aria-checked” per le caselle di controllo personalizzate, con il valore “mixed” per gli stati a tre stati. “aria-pressed” per i pulsanti di attivazione/disattivazione. “aria-disabled” quando l’elemento è ancora focalizzabile ma non utilizzabile, al contrario dell’attributo nativo “disabled”, che lo rimuove dall’ordine di tabulazione.
Relazioni. “aria-controls” indica quale elemento controlla un pulsante. “aria-owns” riorganizza l’albero dell’accessibilità quando il DOM non riflette la relazione visiva. “aria-activedescendant” ti consente di mantenere il focus su un contenitore mentre annuncia l’elemento attivo, uno schema comune nelle caselle combinate.
Regioni live. aria-live="educato" o "assertivo" definiscono l’urgenza. aria-atomic="true" fa sì che venga annunciato l’intero blocco anziché solo la parte modificata. aria-relevant filtra di cui vengono annunciate le modifiche.
Un dettaglio che spesso viene trascurato: gli attributi ARIA funzionano solo su elementi con un ruolo valido. “aria-expanded” su un "
Correlato: — La che accredita la tua esperienza di accessibilità.
, ”false”), non valori booleani JavaScript; scrivere aria-expanded=“false”` come proprietà booleana produrrà risultati incoerenti.
Errori che compromettono l’accessibilità di un widget
L’errore più costoso è usare ARIA per modificare un HTML mal strutturato. Aggiungere role="navigation" a un <div> quando si aveva un <nav> disponibile duplica le regioni e confondere la navigazione per punti di riferimento.
Il secondo errore è il focus. Un widget modale che non sposta il focus quando viene aperto, non lo intrappola mentre è aperto e non lo riporta al trigger dopo la chiusura lascia che l’utente della tastiera navighi attraverso contenuti invisibili. L’elemento nativo <dialog> risolve in parte questo problema, ma non tutto: riportare il focus è ancora responsabilità dello sviluppatore.
Il terzo errore viene nascosto con elementi con aria-hidden che continuano a essere visibili. Un menu chiuso con aria-hidden="true" ma senza display: none o visibility: hidden mantiene i suoi collegamenti nell’ordine di tabulazione e l’utente mette a fuoco elementi che non è possibile visualizzare. La combinazione corretta è quella di nascondere visivamente e dall’albero di accessibilità contemporaneamente.
Il quarto errore è l’assenza del nome accessibile. Un <button> con una singola icona SVG richiede un’aria-label o un <span class="visually-hidden"> con testo. Un SVG decorativo richiede aria-hidden="true" e focusable="false" quindi Internet Explorer e alcuni browser meno recenti non lo includono nell’ordine di tabulazione.
Strumenti per provare ruoli e attributi ARIA
Non esiste uno strumento che sostituisca il test con un vero screen reader, ma la combinazione di vari strumenti rileva la maggior parte degli errori nei ruoli e negli attributi dell’aria.
Convalida statica. Il validatore ARIA del W3C (parte di Nu HTML Checker) rileva ruoli inesistenti, attributi scritti in modo inadeguato e combinazioni proibite. ax DevTools e Lighthouse evidenziano i ruoli senza nomi accessibili e attributi obbligatori mancanti.
Ispezione dell’albero dell’accessibilità. Chrome e Firefox DevTools ti consentono di vedere l’albero dell’accessibilità esattamente come viene ricevuto dalla tecnologia assistiva. È il modo più veloce per verificare se un ruolo è stato effettivamente applicato e quale nome accessibile ha calcolato il browser.
Test manuale. Naviga nell’intero widget solo con la tastiera (Tab, Maiusc+Tab, frecce, Invio, Spazio, Escape) e poi con NVDA su Windows, JAWS se disponibile o VoiceOver su macOS e iOS. La combinazione di un lettore desktop e di uno mobile copre la maggior parte dei casi reali.
Documentazione di riferimento. La ARIA Authoring Practices Guide (APG) del W3C include modelli completi con esempi di tastiera e codice. Questa è la fonte che dovrebbe essere consultata prima di inventare un nuovo modello.
Come decidere in un progetto XHTML/CSS reale
Sui siti XHTML con CSS e JavaScript leggeri, la strategia più conveniente è iniziare con HTML nativo e aggiungere ARIA solo dove il nativo non arriva. Un modulo con <label>, <fieldset> e <legend> corretti richiede pochissima ARIA. Nemmeno una tabella di dati con <th scope> lo fa. I ruoli ARIA entrano in gioco quando compaiono modelli che l’HTML non copre: schede, accordion, caselle combinate con filtri, finestre di dialogo modali e notifiche dinamiche.
Si consiglia di documentare ogni utilizzo dei ruoli e degli attributi ARIA nel codice stesso con un commento che ne spieghi il motivo. Quando qualcuno rifattorizza il componente sei mesi dopo, saprà se gli “aria-controls” sono ancora necessari o sono diventati orfani. Gli attributi ARIA orfani, che puntano a “id” che non esistono più, sono una fonte silenziosa di errori che nessun validatore rileva in modo affidabile.
Infine, considerate l’accessibilità come parte della definizione di “fatto” del componente, non come un controllo successivo. Un widget con ruoli ARIA testato con tastiera e screen reader fin dal primo commit costa molto meno di uno riparato dopo l’audit.
Punti chiave
- Ruoli e attributi ARIA non aggiungono comportamenti: un ruolo senza tastiera e gestione del focus è peggio che non avere nulla.
- La prima regola di ARIA è utilizzare l’HTML nativo ogni volta che esiste;
<button>,<dialog>e<details>coprono più casi di quanto si possa pensare. - Gli attributi sono raggruppati in etichette, stati, relazioni e regioni attive; ogni famiglia risolve un problema diverso.
role="alert"interrompe erole="status"attende: la scelta errata satura l’utente dello screen reader.- I valori booleani ARIA sono stringhe (“true”
/”false”`) e gli attributi funzionano solo su elementi con un ruolo valido. - È obbligatorio effettuare il test con una tastiera e un vero screen reader; i validatori rilevano solo una parte degli errori.
Fonti e ulteriori letture
- WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) è una specifica tecnica pubblicata dal World Wide Web Consortium (W3C) che…
Domande frequenti
Qual è la differenza tra un ruolo e un attributo ARIA?
Un ruolo definisce cos’è un elemento per la tecnologia assistiva, come role="tab" o role="dialog". Un attributo descrive il suo stato o le sue relazioni, come “aria-expanded” o “aria-labelledby”. I ruoli vengono applicati all’elemento che rappresenta il componente; gli attributi vengono solitamente applicati allo stesso elemento o a quelli ad esso correlati.
¿Quando devi usare ARIA nel luogo del linguaggio HTML nativo?
Solo quando non è presente alcun elemento HTML che copra il pattern. La prima regola del W3C ARIA è esplicita: se c’è un elemento nativo, usatelo. I ruoli ARIA sono necessari per schede, accordion, caselle combinate con filtri e finestre di dialogo modali, tra gli altri modelli che l’HTML non può implementare da solo.
Cosa significa che un elemento ha un nome accessibile?
Un nome accessibile è il testo che lo screen reader annuncia quando si focalizza l’elemento. Viene calcolato dal contenuto, da “aria-label”, da “aria-labeledby” o da una "
Perché il mio role="button" non ha risposto al comando?
Perché ARIA non aggiunge comportamenti. Un <div role="button"> necessita di tabindex="0" per ricevere il focus e i gestori keydown per Invio e Spazio. La soluzione più semplice e robusta è utilizzare l’elemento nativo <button>, che include già focus, attivazione da tastiera e invio del modulo.
È sbagliato usare aria-hidden="true"?
È corretto nascondere contenuti decorativi o duplicati dall’albero dell’accessibilità, ma non dovrebbe mai essere applicato agli elementi che ricevono il focus. Se un elemento focalizzabile viene lasciato con aria-hidden="true", l’utente della tastiera potrebbe focalizzare qualcosa che lo screen reader non annuncia. Combinalo sempre con un effettivo occultamento visivo.
Quali strumenti convalidano i ruoli e gli attributi ARIA?
Il W3C Nu HTML Checker include la convalida dei ruoli e degli attributi ARIA e rileva ruoli inesistenti o combinazioni vietate. axe DevTools e Lighthouse segnalano ruoli senza un nome accessibile e attributi obbligatori mancanti. Per verificare il risultato finale, l’ispettore dell’albero dell’accessibilità nel browser DevTools mostra esattamente cosa riceve la tecnologia assistiva.
Domande frequenti
¿Qual è la differenza tra un ruolo e un attributo ARIA?
Un ruolo definisce cos'è un elemento per la tecnologia assistiva, come role='tab' o role='dialog'. Un attributo descrive il suo stato o le sue relazioni, come aria-expanded o aria-labelledby. I ruoli vengono applicati all'elemento che rappresenta il componente; gli attributi vengono solitamente applicati allo stesso elemento o a quelli ad esso correlati.
Vuoi usare ARIA nel luogo in cui si trova l'HTML nativo?
Solo quando non è presente alcun elemento HTML che copra il pattern. La prima regola del W3C ARIA è esplicita: se c'è un elemento nativo, usatelo. I ruoli ARIA sono necessari per schede, accordion, caselle combinate con filtri e finestre di dialogo modali, tra gli altri modelli che l'HTML non può implementare da solo.
Cosa significa che un elemento ha un nome accessibile?
Un nome accessibile è il testo che lo screen reader annuncia quando si focalizza l'elemento. Viene calcolato dal contenuto, da aria-label, da aria-labeledby o da una <label> associata, in un ordine di priorità definito dalle specifiche. Un ruolo interattivo senza un nome accessibile è un controllo che l'utente non può identificare.
¿Per quale motivo il mio `role='button'` non ha risposto al teclado?
Perché ARIA non aggiunge comportamenti. Un <div role='button'> necessita di tabindex='0' per ricevere i gestori di focus e keydown per Invio e Spazio. La soluzione più semplice e robusta è utilizzare l'elemento nativo <button>, che include già focus, attivazione da tastiera e invio del modulo.
¿È sbagliato usare `aria-hidden='true'`?
È corretto nascondere contenuti decorativi o duplicati dall'albero dell'accessibilità, ma non dovrebbe mai essere applicato agli elementi che ricevono il focus. Se un elemento focalizzabile viene lasciato con aria-hidden='true', l'utente della tastiera può focalizzare qualcosa che lo screen reader non annuncia. Combinalo sempre con un vero nascondiglio visivo.
Quali strumenti convalidano i ruoli e gli attributi ARIA?
Il W3C Nu HTML Checker include la convalida dei ruoli e degli attributi ARIA e rileva ruoli inesistenti o combinazioni vietate. ax DevTools e Lighthouse segnalano ruoli senza un nome accessibile e attributi obbligatori mancanti. Per verificare il risultato finale, l'ispettore dell'albero dell'accessibilità nel browser DevTools mostra esattamente cosa riceve la tecnologia assistiva.
¿Compili WCAG senza toccare il codice?
Sovrapposizione di IA che promette il completamento del WCAG in 48 ore