Foglio informativo sui ruoli ARIA: le migliori scelte a confronto

Un cheat sheet dei ruoli ARIA è un riferimento che associa ogni ruolo ARIA al suo elemento HTML nativo equivalente, alla sua categoria (widget, landmark, struttura, live region o finestra) e alle proprietà e agli stati che lo accompagnano. WAI-ARIA 1.2 definisce 82 ruoli, e la maggior parte dei progetti ne necessita solo tra 15 e 20 in modo ricorrente. Questo comparativo riunisce i migliori fogli di riferimento disponibili nel 2026 e spiega quale scegliere in base al proprio flusso di lavoro.

Perché un cheat sheet dei ruoli ARIA è ancora necessario

Le specifiche come WAI-ARIA 1.2 e la sua successora WAI-ARIA 1.3 sono documenti densi, pensati per gli implementatori di browser e tecnologie assistive, non per chi deve impaginare un modulo un martedì pomeriggio. La prima regola di ARIA —usare l’HTML nativo ogni volta che esiste— risolve la maggior parte dei casi, ma ci sono pattern che non hanno un equivalente nativo: schede (tabs), alberi (trees), griglie interattive, combobox con autocompletamento, menu con sottomenu. È qui che un foglio di riferimento fa risparmiare tempo e, soprattutto, evita errori.

L’errore più comune non è dimenticare un ruolo, ma aggiungerne uno non necessario. Un <button> con role="button" non apporta nulla e può rompere il comportamento nativo in alcuni lettori di schermo. Un cheat sheet ben fatto indica esplicitamente quali ruoli sono ridondanti sugli elementi nativi, quali ruoli richiedono la gestione del focus tramite JavaScript e quali attributi sono obbligatori rispetto a quelli opzionali.

La seconda ragione è la verifica. I ruoli hanno relazioni di proprietà: aria-labelledby punta a un id, aria-activedescendant esige che l’elemento referenziato esista e sia visibile, aria-owns è giustificato solo quando l’ordine del DOM non coincide con l’ordine visivo. Una tabella che incroci ruolo, attributi richiesti e attributi proibiti rileva i guasti prima che arrivino a un audit.

Cosa deve includere un buon cheat sheet dei ruoli ARIA

Un foglio di riferimento utile per lo sviluppo front-end soddisfa cinque criteri. Li elenco perché sono esattamente quelli che ho usato per valutare le opzioni di questo comparativo.

• Copertura di tutte e cinque le categorie di ruoli. WAI-ARIA raggruppa i ruoli in summaries, widget, struttura del documento, landmark e live regions. I summaries (roletype, widget, input) non sono usati nel framework; un buon riferimento riporta i dati della forma visibile.
• Equivalente HTML nativo per il ruolo. Senza questa colonna, il riferimento spingerebbe a usare ARIA dove non serve.
• Attributi obbligatori, supportati e proibiti. role="checkbox" richiede aria-checked; role="heading" richiede aria-level; role="presentation" non è consentito.
• Pattern di tastiera associato. Un ruolo senza gestione della tastiera è una promessa non mantenuta. role="tablist" implica l’uso di frecce destra/sinistra, Home ed End.
• Formato ricercabile. Ricerca, filtro per categoria, versione della specifica e possibilità di copiare il frammento di codice.

Comparativa: i migliori riferimenti per i ruoli ARIA nel 2026

La tabella seguente riassume le opzioni più solide. Nessuna è a pagamento; tutte sono mantenute attive e citano la versione della specifica che coprono.

Correlato: accessiBe — Sovrapposizione di IA che promette il completamento del WCAG in 48 ore.

Risorsa	Approccio	Categorie coperte	Equivalente nativo	Pattern di tastiera	Ideale per
WAI-ARIA Authoring Practices Guide (APG), W3C	Pattern completi con esempi	Widget, landmark, struttura, live regions	Sì, in ogni pattern	Sì, dettagliato	Implementare un widget concreto
MDN Web Docs, riferimento ruoli ARIA	Scheda per ruolo	Tutte, inclusi astratti	Sì	Parziale	Consultare un ruolo puntuale
ARIA Authoring Practices, indice dei ruoli	Tabella ruolo $\to$ attributi	Widget e struttura	Parziale	No	Verificare attributi richiesti
Deque University, ARIA reference	Schede con note di supporto	Widget e landmark	Sì	Parziale	Conoscere il supporto reale per lettore
A11Y Project Checklist	Lista di verifica	Trasversale	Non applicabile	No	Auditare prima di pubblicare
HTML-ARIA (W3C), tabella delle equivalenze	Ruolo consentito per elemento	Tutte	Sì, è il suo scopo	No	Decidere se ARIA è necessario

WAI-ARIA Authoring Practices Guide (APG)

L’APG del W3C è il riferimento canonico per i pattern. Ogni pattern include struttura HTML, ruoli, stati, interazione da tastiera e un esempio funzionale. Il suo punto di forza è che non si limita a elencare i ruoli: spiega il comportamento atteso. Il suo punto debole è che non è una tabella rapida; per consultare «quali attributi ha role="slider"» bisogna navigare fino al pattern corrispondente.

L’APG raggruppa i widget più comuni: accordion, alert, breadcrumb, button, checkbox, combo box, dialog, disclosure, feed, grid, link, list box, menu, menu bar, radio group, slider, rotary knob, switch, table, tab list, toolbar, tooltip, grid tree e tree view. Se il tuo progetto ne usa uno di questi, cercalo qui.

MDN Web Docs: il riferimento per ruolo

MDN mantiene una pagina per ogni ruolo ARIA, con descrizione, attributi richiesti, attributi consentiti, problemi di accessibilità associati e link alla specifica. Questa è l’opzione più rapida quando sai cosa stai cercando. La copertura include ruoli astratti e ruoli in uso, sebbene molti promemoria siano omessi.

Vale la pena dare un'occhiata: UserWay — Widget di accessibilità con piano gratuito per empezar hoy mismo.

Un dettaglio pratico: MDN indica quali ruoli sono obsoleti o a rischio di eliminazione nelle versioni future della specifica. Consultare tale indicazione evita di adottare un ruolo che scomparirà.

HTML-ARIA: la tabella che evita ARIA non necessario

La specifica HTML-ARIA del W3C definisce, per ogni elemento HTML, quali ruoli ARIA possono essere applicati e quali sono ridondanti. È lo strumento decisivo quando si dubita tra l’uso di un elemento nativo o di un div con ruolo. Se il ruolo che vuoi applicare appare come ridondante per quell’elemento, la risposta è di non aggiungerlo.

Deque University e A11Y Project

Deque University offre schede di ruolo con note sul supporto reale nei lettori di schermo, aspetto che la specifica non copre perché non è il suo compito. L’A11Y Project Checklist non è un cheat sheet di ruoli, ma funziona come lista di verifica pre-pubblicazione e completa bene le precedenti.

Come scegliere in base al proprio caso

La decisione dipende da tre domande. Primo: sai già di quale ruolo hai bisogno? Se la risposta è sì, MDN è la via più breve. Secondo: stai costruendo un widget con interazione complessa? Allora ti serve l’APG, perché il ruolo da solo non descrive il comportamento della tastiera. Terzo: dubiti tra HTML nativo e ARIA? Consulta HTML-ARIA prima di qualsiasi altra fonte.

Per i team che lavorano con XHTML e CSS senza framework, la combinazione più efficiente è solitamente: HTML-ARIA per decidere, APG per implementare e MDN per verificare gli attributi. Un cheat sheet di una sola pagina serve come memoria a breve termine, ma non sostituisce queste tre fonti quando si presenta un caso limite.

Un criterio aggiuntivo da applicare: se il ruolo richiede JavaScript per funzionare correttamente (gestione del focus, aggiornamento di aria-expanded, sincronizzazione di aria-selected), trattalo come una decisione di architettura, non come un attributo decorativo. I ruoli di widget senza la logica associata generano più barriere dell’assenza di ruolo.

Correlato: IAAP CPACC / WAS Certification — La certificazione professionale che accredita la tua esperienza di accessibilità.

Errori frequenti che nessun cheat sheet evita da solo

I ruoli di landmark duplicati confondono la navigazione per regioni. Un role="main" su un <main> è ridondante; due role="navigation" senza etichetta distintiva sono ambigui. La soluzione è aria-label o aria-labelledby su ogni landmark ripetuto.

I ruoli di widget su elementi non focalizzabili rompono l’interazione. role="button" su un <div> esige tabindex="0" e la gestione di Invio e Spazio. Senza questi, il ruolo annuncia un pulsante che non può essere attivato da tastiera.

Gli stati desincronizzati sono la causa più comune di calo dell’accessibilità. Un aria-expanded che non cambia per aprire un accordion, un aria-selected che non si aggiorna quando cambia la scheda o un aria-checked in un role="switch" che rimane fisso. Nessuna tabella lo rileva: è necessario testare con la tastiera e con un lettore di schermo reale.

Vale la pena dare un'occhiata: Deque axe DevTools Pro — Lo standard industriale per testare l'accessibilità durante lo sviluppo.

L’uso di ruoli astratti nel markup è un errore di principio. role="widget", role="input" o role="section" non devono apparire nell’HTML; esistono solo per la gerarchia della specifica.

Punti chiave

• WAI-ARIA 1.2 definisce 82 ruoli, ma la maggior parte dei progetti ne usa solo tra 15 e 20 in modo ricorrente.
• La prima regola di ARIA —usare l’HTML nativo quando esiste— rende la tabella HTML-ARIA del W3C il riferimento più importante prima di scrivere qualsiasi ruolo.
• L’APG del W3C è insuperabile per i pattern di widget perché include l’interazione da tastiera; MDN è più rapida per consultare un ruolo specifico.
• Un ruolo senza gestione del focus e senza aggiornamento degli stati genera più barriere di accessibilità che non usare ARIA.
• Nessun cheat sheet sostituisce il test con tastiera e lettore di schermo: gli stati desincronizzati si rilevano solo nell’uso reale.

Domande frequenti

Quanti ruoli ARIA esistono?

WAI-ARIA 1.2 definisce 82 ruoli, suddivisi in cinque categorie: astratti, widget, struttura del documento, landmark e live regions. I ruoli astratti non vengono mai applicati nel markup; servono per organizzare la gerarchia della specifica. In pratica, un progetto tipico utilizza tra 15 e 20 ruoli distinti.

Qual è il miglior cheat sheet dei ruoli ARIA?

Dipende dall’uso. Per implementare un widget con tastiera, la WAI-ARIA Authoring Practices Guide del W3C è il riferimento più completo. Per consultare gli attributi di un ruolo specifico, MDN Web Docs è più rapida. Per decidere se un ruolo è necessario su un elemento HTML, la tabella HTML-ARIA del W3C è la fonte decisiva.

Devo usare ARIA se esiste un elemento HTML nativo?

No. La prima regola di ARIA stabilisce che se esiste un elemento HTML con la semantica e il comportamento di cui hai bisogno, si usa quell’elemento invece di un div con ruolo. Aggiungere role="button" a un <button> è ridondante e può alterare il comportamento nativo in alcuni lettori di schermo.

Qual è la differenza tra un ruolo di widget e un ruolo di landmark?

I ruoli di widget descrivono controlli interattivi —button, checkbox, slider, tablist— e richiedono la gestione del focus e della tastiera. I ruoli di landmark descrivono regioni della pagina —main, navigation, banner, contentinfo— e servono per la navigazione per regioni. Un singolo elemento non dovrebbe assolvere entrambe le funzioni.

I ruoli ARIA cambiano tra le versioni della specifica?

Sì. WAI-ARIA 1.2 ha aggiunto ruoli come blockquote, caption, code, deletion, emphasis, insertion, meter, paragraph, strong, subscript e superscript. Alcuni ruoli sono diventati obsoleti nelle versioni successive. Conviene controllare su MDN o nella specifica stessa se un ruolo è ancora valido prima di adottarlo.

Un cheat sheet dei ruoli ARIA basta per essere conformi alle WCAG?

No. I ruoli ARIA sono solo una parte del criterio 4.1.2 Nome, ruolo e valore, ma le WCAG 2.2 includono molti altri requisiti: contrasto, focus visibile, dimensione dell’area di interazione, testo alternativo, struttura degli intestazioni. Un cheat sheet aiuta a implementare correttamente i ruoli, non a soddisfare l’insieme dei criteri di conformità.

Fonti e ulteriori letture

• Cheat sheet — Wikipedia: A cheat sheet (also cheatsheet) or crib sheet or job aid is a concise set of notes used for quick reference. Cheat sheets were historically used by students without…