Elenco dei ruoli ARIA: migliori referenze a confronto

L’elenco completo dei ruoli ARIA comprende 82 valori definiti nelle specifiche WAI-ARIA 1.2 del W3C, organizzati in sei categorie funzionali: ruoli del documento, del punto di riferimento, del widget, della struttura, della finestra e dello stato astratto. Scegliere il riferimento adatto per consultarlo dipende dalla necessità di una tabella rapida, documentazione con esempi di codice o una guida alle decisioni su quando applicare ogni ruolo.

Punti chiave

• La specifica WAI-ARIA 1.2 definisce 82 ruoli, ma solo un sottocongiunto ridotto viene utilizzato nella pratica diaria di un sito XHTML/CSS accessibile.
• La prima regola di ARIA è ancora vigente: se esiste un elemento HTML nativo con la semantica necessaria, usalo invece di aggiungere un ruolo.
• I ruoli astratti (come role="widget" o role="input") non devono essere scritti nel marcato; servono solo come base tassonomica.
• Una referenza utile per il front-end deve includere il ruolo, i suoi attributi ARIA obbligatori, gli stati consentiti e un esempio di marcato reale.
• I ruoli del punto di riferimento e del widget concentrano la maggior parte degli errori rilevati dagli auditor automatici come axe-core o Lighthouse.

Cos’è un ruolo ARIA e perché è necessaria una lista affidabile

Un ruolo ARIA è un valore che viene assegnato a un elemento mediante l’attributo role per comunicare alle tecnologie di assistenza che tipo di componente rappresenta. Il navigatore espone questo ruolo attraverso l’albero di accessibilità e un lettore di schermo come NVDA, JAWS o VoiceOver lo traduce in un annuncio concreto: “pulsante”, “scheda”, “regione”, “finestra di dialogo”.

La specifica WAI-ARIA, mantenuta dal W3C all’interno del gruppo di lavoro ARIA, definisce ogni ruolo insieme ai suoi attributi di stato e proprietà consentiti. La versione 1.2 è la raccomandazione attuale stabile e ARIA 1.3 è in fase di sviluppo. Per uno sviluppatore che lavora con XHTML e CSS, la lista dei ruoli non è un catalogo decorativo: ogni valore mal applicato genera un conflitto tra la semantica nativa dell’elemento e quella dichiarata, e i lettori di schermo risolvono questo conflitto in modi diversi a seconda del browser.

La documentazione ufficiale dei ruoli di ARIA su MDN (Mozilla Developer Network) è il riferimento tecnico più consultato in spagnolo e inglese, ma non è l’unica. Esistono schede di riferimento, guide degli utenti e strumenti di convalida che soddisfano esigenze distinte. Confrontarli ti aiuta a scegliere quello che si adatti al tuo flusso di lavoro.

Le sei categorie di ruoli ARIA

La tassonomia ufficiale raggruppa i ruoli in base alla propria funzione. Conoscere le categorie evita di cercare nell’elenco sbagliato.

Ruoli del documento. Descrive la struttura di una pagina o sezione: article, document, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Molti elementi HTML nativi duplicati, quindi raramente vengono scritti a mano.

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

Ruoli Landmark. Definisci le aree navigabili della pagina: banner, complementary, contentinfo, form, main, navigation, region, search. Questo è quello più utilizzato sui siti con semantica HTML incompleta.

Ruoli widget. Rappresenta i controlli interattivi: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, “treeitem”. Richiede la messa a fuoco e la gestione della tastiera.

Ruoli della struttura. I widget dell’organizzazione includono: application, grid, group, listbox, menu, menubar, radiogroup, tablist, tree, treegrid, rowgroup, columnheader, rowheader.

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

Ruoli finestra. Gestione dei contenuti sovrapposti o modali: alertdialog, dialog.

Ruoli astratti. Nessun elemento è scritto nel markup: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. Servono alla specifica per ereditare le proprietà tra i ruoli.

Comparativa: i migliori riferimenti per i ruoli ARIA

La seguente tabella confronta i riferimenti più utilizzati dagli sviluppatori di lingua spagnola secondo criteri pratici.

Riferimento	Tipo	Idiomi	Esempi di codice	Ideale per
Documenti Web MDN (Ruoli ARIA)	Documentazione ufficiale	Multilingue (incluye español)	Sì, per ruolo	Consulta tecnica profonda
WAI-ARIA 1.2 (W3C)	Specificazione normativa	Inglese	No	Verificare il comportamento esatto
Guida pratica per la creazione di WAI-ARIA	Guida ai pattern	Inglese	Sì, pattern completi	Widget implementati con tastiera
Foglio di riferimento (cheat sheet)	Tabella riassuntiva	Inglese	Minimi	Risposta rapida nell’editor
accessibilità.build (riferimento ARIA)	Riferimento pratico	Inglese	Sì	Impara con esempi commentati
Audit (axe-core, Lighthouse)	Strumento	Multilingue	No	Rileva ruoli non validi

La scelta dipende dal momento. Durante la scrittura del marcato, un foglio di riferimento compatto vince in velocità. Nel debuggare un widget che non annuncia correttamente il proprio stato, le specifiche del W3C e la guida ai pattern di WAI sono le fonti che risolvono il problema.

Come decidere quale ruolo applicare: criteri pratici

La decisione corretta è sempre partendo dal voler evitare ARIA. Questi criteri, in ordine, evitano la maggior parte degli errori.

1. Esiste un elemento HTML nativo? Un <button> ha già il ruolo implicito di un pulsante. L’aggiunta di role="button" è ridondante e può introdurre conflitti.
2. Il ruolo richiede attributi obbligatori? role="checkbox" richiede aria-checked. role="slider" richiede aria-valuenow, aria-valuemin e aria-valuemax. Se non riesci a mantenere questi stati, il ruolo danneggia più di quanto aiuta.
3. Il ruolo implica la gestione della tastiera? I ruoli widget richiedono la navigazione con le frecce, Home, Fine ed Esc a seconda dello schema. Un role="tablist" senza la gestione delle frecce è peggio che non averlo.
4. Il ruolo è astratto? Se è nella lista dei ruoli astratti, non va scritto.
5. Il ruolo è obsoleto o in disuso? Alcuni valori sono stati modificati tra ARIA 1.0 e 1.2. Consultare sempre la versione attuale.

La prima regola per l’utilizzo di ARIA, riconosciuta nella guida tecnica del W3C, è il principio: utilizzare HTML nativo quando possibile. ARIA è una patch per quando l’HTML non è sufficiente, non un sostituto.

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

Errori frequenti durante la consultazione e l’applicazione dell’elenco dei ruoli

Un errore abituale consiste nel copiare un ruolo da una foglio di riferimento senza verificare gli attributi richiesti. role="combobox" in ARIA 1.2 è cambiato rispetto a 1.0 e ora aspetta aria-expanded e una relazione con un listbox tramite aria-controls. Applicare la versione antica compromette l’annuncio nei lettori aggiornati.

È anche comune usare role="presentation" o role="none" per “ripulire” la semantica senza capire che questo elimina l’elemento dall’albero dell’accessibilità, inclusi in alcuni casi i suoi figli. Questo appare anche con la frequenza role="application", che trasferisce tutto il controllo della tastiera al widget e disabilita le scorciatoie dello screen reader; è riservato ad applicazioni web complesse, non ai moduli.

I ruoli dei punti di riferimento duplicati generano confusione: due role="main" nella stessa pagina, o un role="banner" all’interno di un <article>, producono una navigazione in regioni incoerenti. La convalida con axe-core o con gli strumenti di accessibilità del browser rileva molti di questi casi, anche se nessun strumento automatico sostituisce la prova con il lettore di schermo reale.

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

Strumenti per convalidare i ruoli nel tuo marcato

La verifica dei ruoli combina ispezione manuale e automatizzazione. I DevTools di Chrome e Firefox includono un pannello di accessibilità che mostra l’albero come lo riceve il sistema operativo, con il ruolo calcolato per ogni nodo. È la forma più diretta per vedere se un ruolo dichiarato sopravvive o viene sovrascritto dalla semantica nativa.

axe-core, integrato in Lighthouse e disponibile come estensione, contrassegna ruoli non validi, attributi obbligatori ausenti e combinazioni contraddittorie. L’estensione Accessibility Insights for Web, basata sulle regole di axe, aggiunge le guide di controllo. Per effettuare prove con utenti reali, NVDA su Windows e VoiceOver su macOS offrono la verifica definitiva: nessun validatore rileva se l’annuncio risulta comprensibile nel contesto.

La documentazione sull’accessibilità di MDN e la guida degli utenti di WAI-ARIA del W3C sono le due fonti che ti conviene tenere aperte durante lo sviluppo. La prima spiega ogni ruolo; la seconda mostra come si combina con i componenti completi.

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

Quanti ruoli ARIA esistono?

La specifica W3C WAI-ARIA 1.2 definisce 82 ruoli in totale, divisi tra ruoli documento, punto di riferimento, widget, struttura, finestra e astratto. In questo contesto, solo una piccola parte viene utilizzata nello sviluppo normale: i ruoli astratti non vengono mai scritti e molti ruoli del documento duplicano elementi HTML nativi.

Qual è la differenza tra un ruolo ARIA e un attributo ARIA?

Un ruolo ARIA descrive ciò che è un elemento, mentre gli attributi ARIA descrivono il suo stato o le sue proprietà. Ad esempio, role="checkbox" identifica il componente e aria-checked="true" comunica se è selezionato. I ruoli vengono assegnati con l’attributo “role”; gli stati e le proprietà utilizzano il prefisso “aria-”.

Devo usare ARIA se uso già l’HTML semantico?

Nella maggior parte dei casi, no. L’HTML semantico espone già ruoli impliciti: <nav> è equivalente a role="navigation" e <main> è equivalente a role="main". L’aggiunta esplicita del ruolo è ridondante e può creare conflitti. ARIA è riservata ai componenti che l’HTML non copre, come schede, alberi o menu complessi.

Quali ruoli ARIA non devo mai scrivere nel markup?

I ruoli astratti non dovrebbero mai apparire: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget e window. Esistono solo per la specifica per definire l’ereditarietà delle proprietà tra i ruoli. Scriverli produce un ruolo non valido che i validatori contrassegnano.

Come verificare se un ruolo ARIA funziona correttamente?

La verifica combina tre passaggi: ispezionare l’albero di accessibilità nei DevTools del browser per confermare il ruolo calcolato, passare un validatore come axe-core per rilevare gli attributi obbligatori mancanti e testare con un vero screen reader come NVDA o VoiceOver. Solo l’ultimo passaggio conferma che l’annuncio è comprensibile per una persona.

I ruoli ARIA cambiano tra le versioni delle specifiche?

Sì. ARIA 1.1 ha aggiunto ruoli come “feed” e “switch”, e ARIA 1.2 ha modificato il comportamento di “combobox” e ha consolidato altri valori. ARIA 1.3 è in fase di sviluppo. Consultare sempre la versione in vigore delle specifiche per evitare di applicare pattern obsoleti che i lettori di schermi moderni interpretano in forma distinta.