Cosa sono i ruoli ARIA? Una guida pratica per gli sviluppatori

Perché esistono i ruoli ARIA

Per capire cosa sono i ruoli aria, bisogna vedere che risolvono un problema strutturale che l’HTML da solo non può risolvere. Gli elementi HTML nativi hanno una semantica implicita: un "" si annuncia come un pulsante, può essere focalizzato, risponde a Invio e alla barra spaziatrice e visualizza uno stato premuto quando necessario.

Quando gli sviluppatori creano widget personalizzati (una casella combinata, un pannello a schede, una visualizzazione ad albero), spesso utilizzano <div> e <span>, che non contengono semantica. I ruoli ARIA colmano questa lacuna consentendo agli autori di dichiarare esplicitamente il significato mancante.

La specifica WAI-ARIA è mantenuta dall’Accessible Rich Internet Applications Working Group del W3C. La prima versione, ARIA 1.0, è diventata una raccomandazione del W3C nel 2014; ARIA 1.1 è seguita nel 2017 e ARIA 1.2 ha raggiunto lo stato di Raccomandazione nel 2023. Ruoli, stati e proprietà sono stati aggiunti con ogni revisione e ciascuno è collegato a un documento sulle pratiche di creazione che descrive il comportamento previsto della tastiera.

Una distinzione fondamentale separa i ruoli dalle altre due categorie ARIA. I ruoli rispondono: “Cos’è questo?” Gli stati e le proprietà rispondono: “In che condizioni è?” e “A cosa è correlato?” Un role="checkbox" dichiara il tipo di widget; `aria-checked=“true”“ indica il suo stato attuale. Confondere i due è una delle cause più comuni di widget personalizzati non funzionanti.

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

Le sei categorie di ruoli

Per capire cosa sono i ruoli ARIA, è utile sapere che la specifica ARIA raggruppa i ruoli in sei famiglie. Comprendere la famiglia consente di prevedere quali stati e proprietà sono supportati da un ruolo e quali modelli di tastiera si applicano.

I ruoli astratti vengono utilizzati solo per organizzare la tassonomia. Gli autori non devono mai scrivere role="widget" o role="input" nel markup; ciò si traduce in un comportamento indefinito e la convalida fallisce. Le restanti cinque categorie sono quelle effettivamente applicate.

Ruoli impliciti e prima regola di ARIA

Ogni elemento HTML ha una funzione ARIA implicita (che spiega cosa sono i ruoli aria) definita dalla specifica HTML Accessibility API Mapping (AAM). Un elemento <nav> ha un role="navigation" implicito. Un <ul> ha un role="list" implicito. Un <h1> fino a <h6> ha role="heading". Una <table> ha role="table".

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

La prima regola del W3C sull’utilizzo di ARIA afferma chiaramente: se un elemento o attributo HTML nativo trasmette già la semantica e il comportamento richiesti, utilizzarlo invece di riutilizzare un elemento con ARIA. Non è necessario aggiungere role="button" a un <button>. Ancora peggio, se aggiungi role="button" a un <div>, riceverai l’annuncio ma nessun comportamento: nessun focus, nessuna attivazione da tastiera, nessun invio di moduli.

La ridondanza non è sempre innocua. Sostituire un ruolo implicito può far perdere la semantica da cui dipende la tecnologia assistiva. Scrivere role="presentation" in una <table> elimina completamente la semantica della tabella, che a volte è intenzionale con le tabelle di layout ma disastrosa con le tabelle di dati.

Come i ruoli interagiscono con stati e proprietà

I ruoli fungono da contenitori per gli stati e le proprietà che supportano. La specifica definisce quali attributi sono validi per quali ruoli e i browser espongono solo le combinazioni supportate nell’albero di accessibilità.

Capire cosa sono i ruoli aria aiuta a sapere che un role="checkbox" supporta aria-checked con i valori true, false o mixed. Un role="slider" supporta aria-valuenow, aria-valuemin, aria-valuemax e facoltativamente aria-valuetext. Un role="combobox" supporta aria-expanded, aria-controls e aria-activedescendant. Applicare aria-checked a un role="button" non ha senso e verrà ignorato o produrrà risultati confusi in alcuni screen reader.

Anche le proprietà richieste sono importanti. Un role="checkbox" senza aria-checked non è valido; lo stato è obbligatorio e non facoltativo. Un role="slider" senza aria-valuenow lascia l’utente incapace di determinare il valore corrente. La specifica ARIA li etichetta come “stati e proprietà richiesti” e i controllori di conformità come axe-core e IBM Equal Access Accessibility Checker ne sottolineano l’assenza.

Ruoli, struttura dell’accessibilità e supporto del browser

I browser traducono le funzioni ARIA in API di accessibilità della piattaforma (UIA su Windows, AXAPI su macOS, ATK/AT-SPI su Linux) e le utilità per la lettura dello schermo utilizzano queste API. Un ruolo che nessun browser assegna correttamente è praticamente invisibile agli utenti.

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

Il supporto varia in base alla funzionalità e al browser. Le funzioni principali come “Pulsante”, “Link”, “Intestazione”, “Elenco” e “Navigazione” sono universalmente supportate. Ruoli più nuovi o più specializzati (“feed”, “matematica”, “doc-nota” dal modulo WAI-ARIA di Digital Publishing) hanno un supporto più frammentario. Il ruolo=“switch” è supportato nei browser moderni, ma è stato annunciato in modo incoerente dieci anni fa.

Testare le combinazioni effettive utilizzate dal tuo pubblico rimane essenziale. Un widget che funziona in NVDA con Firefox potrebbe comportarsi diversamente in VoiceOver con Safari, poiché i due lettori di schermo utilizzano API di piattaforma diverse e applicano euristiche diverse.

Ruoli fondamentali e struttura della pagina

I ruoli di riferimento consentono agli utenti dello screen reader di passare direttamente alle aree di una pagina. Gli otto ruoli fondamentali sono “banner”, “complementary”, “contentinfo”, “form”, “main”, “navigation”, “region” e “search”. L’HTML moderno ha equivalenti nativi per la maggior parte: <header> diventa banner, <footer> diventa contentinfo, <main> diventa main, <nav> diventa navigation, <aside> diventa complementary, <form> con un nome accessibile diventa form e <section> con un nome accessibile diventa region.

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

L’utilizzo di elementi nativi è preferibile perché funzionano anche se CSS o JavaScript falliscono e perché riducono il rischio di conflitti di ruolo/attributo. Il punto di riferimento search non ha un equivalente HTML nativo, quindi role="search" è ancora la scelta corretta per la regione di ricerca.

Un errore comune è applicare role="banner" a un <div> che si trova all’interno di un <main> o <article>. I ruoli di riferimento creano punti di riferimento solo se non sono nidificati all’interno di determinati altri ruoli; un “banner” all’interno di “principale” non verrà affatto visualizzato come punto di riferimento. La posizione nel DOM è importante quanto il valore del ruolo. Per coloro che si chiedono cosa siano i ruoli dell’aria, questi punti di riferimento sono una parte fondamentale delle specifiche.

Ruoli delle regioni attive

Quando si considerano i ruoli dell’aria, i ruoli regionali dal vivo annunciano cambiamenti di contenuto senza cambiare il focus. Le quattro funzioni della regione live sono “alert”, “status”, “log” e “timer”, oltre al più generale “marquee”. Ciascuno porta implicitamente un valore “aria-live”: “alert” e “log” in pratica implicano rispettivamente assertive e polite, mentre “status” implica “educato”.

La scelta tra “avviso” e “stato” è una decisione progettuale con conseguenze reali. Un “avviso” interrompe qualunque cosa stia leggendo lo screen reader, il che è appropriato per errori e notifiche urgenti, ma dannoso se usato eccessivamente. Un status attende una pausa, che coincide con i messaggi di avanzamento e i testi di conferma.

Le regioni attive devono esistere nel DOM prima che il contenuto cambi. Inserendo contemporaneamente un elemento role="alert" e il suo testo spesso non si ottiene alcun annuncio perché la regione non esisteva al momento della modifica. Il modello affidabile consiste nel visualizzare una regione live vuota al caricamento della pagina e aggiornarne il contenuto testuale in un secondo momento.

Quando NON utilizzare i ruoli ARIA

La seconda regola nell’utilizzo di ARIA è che gli autori non dovrebbero modificare la semantica nativa a meno che non sia realmente necessario. La quinta regola prevede che ogni elemento interattivo, indipendentemente dalla sua funzione, deve essere accessibile e focalizzabile tramite tastiera.

L’aggiunta di un ruolo non aggiunge comportamento. role="button" su un <div> fa sì che non riceva il focus, non risponda all’input o alla barra spaziatrice e non invii il modulo. È necessario aggiungere tabindex="0", un gestore di tasti per input e spazio e spesso una gestione dello stato “appropriata al ruolo”. A questo punto, l’utilizzo di un vero "" richiede meno codice e meno errori.

Alcuni ruoli sono attivamente dannosi se applicati in modo errato. role="presentation" e role="none" rimuovono la semantica da un elemento e, in alcune implementazioni, dai suoi discendenti obbligatori. L’applicazione di role="application" commuta gli screen reader in una modalità in cui smettono di intercettare le sequenze di tasti, il che può intrappolare gli utenti se la gestione personalizzata della tastiera è incompleta.

Un quadro decisionale per la scelta dei ruoli

L’esecuzione di una breve sequenza previene la maggior parte degli errori del ruolo ARIA. Per capire cosa sono i ruoli ARIA e come utilizzarli, segui questi passaggi:

1. Identificare il widget o la regione. Denominare ciò che l’elemento è effettivamente in un linguaggio semplice.
2. Verifica la presenza di un equivalente HTML nativo. Consulta la mappatura HTML-AAM. Se <button>, <select>, <details> o <dialog> sono adatti, usalo.
3. Se nessun elemento nativo è adatto, seleziona il ruolo ARIA più vicino. Verifica che esista nella specifica corrente e non sia astratto.
4. Aggiungi stati e proprietà richiesti. Controlla la definizione del ruolo per gli attributi obbligatori.
5. Implementare il modello di interazione della tastiera. Seguire la Guida alle pratiche di creazione WAI-ARIA per il tipo di widget.
6. Test con almeno due combinazioni di screen reader e browser. Verifica gli annunci, gli stati e il flusso della tastiera.

I passaggi da tre a sei sono quelli in cui si verificano la maggior parte degli errori dei widget personalizzati. Saltare la sequenza della tastiera nel passaggio cinque crea un widget che pubblicizza correttamente ma non è utilizzabile, il che è probabilmente peggio che non avere affatto ARIA.

Strumenti di test e convalida

Gli strumenti automatizzati rilevano errori strutturali: valori di ruolo non validi, proprietà richieste mancanti e ruoli applicati a elementi che non li supportano. axe-core, il motore dietro molte estensioni del browser, controlla un sottoinsieme definito di regole ARIA. Anche l’IBM Equal Access Accessibility Checker e il Nu HTML Checker del W3C mostrano un abuso di ruolo.

Gli strumenti automatizzati non possono verificare se un ruolo produce l’annuncio corretto o se l’interazione con la tastiera funziona. È ancora necessario eseguire il test manuale con NVDA e Firefox, JAWS e Chrome o VoiceOver e Safari. L’estensione Accessibility Insights per Web combina controlli automatizzati con una valutazione manuale guidata che include la verifica della tastiera e dell’utilità per la lettura dello schermo.

La stessa specifica ARIA, la WAI-ARIA Authoring Practices Guide e il documento di mappatura HTML-AAM sono i riferimenti autorevoli per quali sono i ruoli aria. Il riferimento ARIA di MDN Web Docs è una fonte secondaria comoda e ben selezionata che fa riferimento alle specifiche per ciascun ruolo.

Punti chiave

• I ruoli ARIA dichiarano cos’è un elemento; WAI-ARIA 1.2 definisce 87 ruoli in sei categorie e i ruoli astratti potrebbero non apparire mai nel markup.
• Gli elementi HTML nativi hanno ruoli impliciti e comportamenti incorporati, quindi la prima regola quando si utilizza ARIA è preferirli a div più role.
• I ruoli richiedono i relativi stati e proprietà supportati: un role="checkbox" senza aria-checked non è valido e non può essere utilizzato.
• L’aggiunta di un ruolo non aggiunge mai il comportamento della tastiera o la focalizzabilità; questi devono essere implementati e testati separatamente.
• I ruoli Landmark e Live Region hanno regole di posizione e tempistica che determinano se funzionano o meno.
• Gli ispettori automatizzati rilevano solo gli errori strutturali; è ancora necessario testare gli screen reader per diverse combinazioni di browser.

Per comprendere quali sono i ruoli ARIA, ricorda che definiscono lo scopo di un elemento per la tecnologia assistiva.

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

Quali sono i ruoli ARIA in termini semplici?

I ruoli ARIA sono etichette che alleghi agli elementi HTML per indicare alla tecnologia assistiva cosa rappresenta l’elemento. Un <div role="button"> viene annunciato come un pulsante anziché come testo generico. I ruoli forniscono significati che il tag sottostante non fornisce, ma non aggiungono da soli alcun comportamento, gestione del focus o supporto della tastiera.

Qual è la differenza tra i ruoli ARIA e gli attributi ARIA?

I ruoli descrivono il tipo di un elemento, mentre gli attributi ne descrivono lo stato, il valore o le relazioni. role="slider" identifica uno slider; aria-valuenow="50" riporta la sua posizione corrente e aria-labelledby punta alla sua etichetta. Ruoli e attributi vengono utilizzati insieme e ciascun ruolo definisce quali attributi supporta.

Quanti ruoli ARIA ci sono?

WAI-ARIA 1.2 definisce 87 ruoli raggruppati in sei categorie: abstract, widget, struttura del documento, landmark, live region e finestra. Ruoli astratti come widget e input esistono solo per la tassonomia interna della specifica e non dovrebbero mai essere scritti in HTML. Il numero cresce ad ogni revisione delle specifiche.

Dovrei utilizzare i ruoli ARIA invece dell’HTML semantico?

No. La prima regola d’uso di ARIA dice di preferire un elemento HTML nativo ogni volta che ne esiste uno con la semantica e il comportamento richiesti. Utilizza <button> anziché <div role="button"> e <nav> anziché <div role="navigation">. I ruoli ARIA sono un fallback per i casi in cui non esiste un elemento nativo adatto.

I ruoli ARIA funzionano in tutti i browser e screen reader?

Ruoli principali come button, link, heading e navigation sono supportati in modo affidabile dai browser e dagli screen reader moderni. Ruoli più nuovi o più specializzati, compresi quelli nel modulo Digital Publishing, forniscono un supporto più variabile. Solo testando le combinazioni specifiche di browser e screen reader utilizzate dal tuo pubblico puoi esserne sicuro.

L’aggiunta di un ruolo ARIA può compromettere l’accessibilità?

Sì. Sostituire un ruolo implicito può far perdere semantica utile, come quando role="presentation" viene applicato a una tabella di dati. L’applicazione di role="application" può bloccare gli utenti se la gestione personalizzata della tastiera è incompleta. Ruoli ridondanti negli elementi nativi creano rumore inutile e occasionalmente portano ad annunci contrastanti.