Che cos'è ARIA? Ruoli, landmark e regioni live

Che cos’è ARIA — e che cosa non è

ARIA è l’acronimo di Accessible Rich Internet Applications. È un insieme di attributi definiti dalla Web Accessibility Initiative (WAI) del W3C che consente agli sviluppatori di comunicare alle tecnologie assistive, come gli screen reader, il significato e lo stato degli elementi dell’interfaccia utente.

La regola più importante su ARIA è anche quella più spesso ignorata: non usare ARIA quando l’HTML nativo può già fare il lavoro. Un elemento <button> si annuncia già come pulsante e risponde agli eventi da tastiera. Un elemento <nav> comunica già agli screen reader il landmark di navigazione. Aggiungere role="button" a un <div> e poi programmarne il comportamento è più difficile da mantenere, più facile da rompere e di solito peggiore per l’accessibilità rispetto all’uso dell’elemento giusto fin dall’inizio.

ARIA non serve a:

• Rendere un contenuto visibile o interattivo — cambia soltanto ciò che la tecnologia assistiva annuncia
• Riparare un accesso da tastiera difettoso — servono comunque tabindex e i listener degli eventi
• Sostituire un HTML semantico ben strutturato

ARIA è genuinamente utile quando l’HTML nativo non ha un elemento per ciò che stai costruendo: un selettore di date, un banner di notifica in tempo reale, una combobox personalizzata, una vista ad albero. In questi casi ARIA ti permette di comunicare la semantica che l’HTML non può esprimere.

I ruoli ARIA

Un ruolo indica alla tecnologia assistiva con che tipo di elemento ha a che fare. Ogni elemento interattivo ha un ruolo implicito derivato dal proprio tag HTML. L’elemento <a> ha il ruolo link. L’elemento <input type="checkbox"> ha il ruolo checkbox. L’elemento <h2> ha il ruolo heading.

Quando costruisci un elemento personalizzato che non ha un equivalente HTML, gli assegni un ruolo esplicito:

<!-- Un interruttore personalizzato costruito a partire da un div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Modalità scura
</div>

Lo screen reader ora annuncerà questo elemento come un controllo di tipo interruttore e ne pronuncerà lo stato di selezione. Senza il ruolo verrebbe annunciato come semplice testo e l’utente non avrebbe alcun modo di sapere che è interattivo.

Ruoli comuni e quando usarli

I ruoli widget descrivono i controlli interattivi:

Ruolo	Usalo quando
button	Un elemento cliccabile personalizzato senza un tag HTML migliore
checkbox	Un interruttore personalizzato a selezione multipla
combobox	Un campo di testo combinato con un elenco a discesa
dialog	Una finestra modale sovrapposta (solo quando non si usa l’elemento nativo <dialog>)
listbox	Un elenco a discesa personalizzato
slider	Un controllo di intervallo personalizzato
switch	Un interruttore acceso/spento
tab, tablist, tabpanel	Un’interfaccia a schede
tooltip	Una breve descrizione mostrata al passaggio del mouse o al focus

I ruoli di struttura del documento descrivono i contenuti non interattivi:

• article — un contenuto autonomo
• figure — un’immagine con una didascalia
• list, listitem — quando serve la semantica di elenco su elementi che non sono elenchi
• presentation / none — rimuove il ruolo implicito di un elemento (da usare raramente e con attenzione)

Un errore critico: aggiungere ruoli senza comportamenti

Ogni ruolo porta con sé un contratto che gli screen reader e gli utenti da tastiera si aspettano venga rispettato. Un role="button" deve rispondere sia a Invio sia a Spazio. Un role="checkbox" deve cambiare stato con Spazio. Un role="link" deve navigare con Invio.

Se aggiungi il ruolo ma non il comportamento corrispondente, stai attivamente ingannando gli utenti di tecnologie assistive. Sentono annunciare un controllo, provano a interagirci con la scorciatoia da tastiera attesa e non succede nulla. È peggio che non usare ARIA affatto.

I landmark ARIA

I landmark sono lo scheletro di navigazione della pagina. Permettono agli utenti di screen reader di saltare tra le regioni principali senza leggere tutto ciò che sta in mezzo — l’equivalente dello sguardo con cui un utente vedente scorre a colpo d’occhio il layout della pagina.

HTML5 ha introdotto elementi semantici che corrispondono direttamente ai ruoli landmark. Usali e i landmark li ottieni gratis:

Elemento HTML	Ruolo landmark	Scopo
<header>	banner	Intestazione di sito (solo quando è l’intestazione di primo livello, non all’interno di <article>)
<nav>	navigation	Un menu di navigazione
<main>	main	Il contenuto principale della pagina
<aside>	complementary	Contenuto secondario correlato al contenuto principale
<footer>	contentinfo	Piè di pagina di sito
<form>	form	Un modulo (solo quando ha un nome accessibile)
<section>	region	Una sezione denominata (solo quando ha un nome accessibile tramite aria-label o aria-labelledby)

Non è necessario aggiungere role="main" a un elemento <main> — è ridondante. I ruoli landmark ARIA servono solo quando non puoi usare l’elemento HTML semantico, per esempio in una codebase legacy che genera <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Articoli correlati">
  <!-- contenuto della barra laterale -->
</div>

Etichettare i landmark quando ce n’è più di uno

Quando una pagina contiene più istanze dello stesso landmark — due elementi <nav>, due elementi <section> con role="region" — ciascuna deve avere un nome accessibile univoco perché gli utenti possano distinguerle:

<nav aria-label="Navigazione principale">...</nav>
<nav aria-label="Navigazione del piè di pagina">...</nav>

Senza etichette, uno screen reader annuncia entrambe semplicemente come “navigazione”. Con le etichette, gli utenti sentono “Navigazione principale, landmark di navigazione” e “Navigazione del piè di pagina, landmark di navigazione” e possono scegliere quella giusta da un elenco di landmark.

Le regioni live ARIA

Una regione live è un’area della pagina il cui contenuto si aggiorna dinamicamente e i cui aggiornamenti devono essere annunciati automaticamente agli utenti di screen reader senza che questi debbano spostare il focus.

L’attributo fondamentale è aria-live. Accetta tre valori:

• off — gli aggiornamenti non vengono annunciati (l’impostazione predefinita per tutti gli elementi)
• polite — gli aggiornamenti vengono annunciati dopo che l’utente ha terminato l’attività in corso
• assertive — gli aggiornamenti interrompono immediatamente qualsiasi cosa lo screen reader stia dicendo

<!-- Un'area per i messaggi di stato popolata dopo l'invio di un modulo -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Il tuo messaggio è stato inviato.';
</script>

Quando il contenuto testuale cambia, uno screen reader con aria-live="polite" attende una pausa nella lettura e poi annuncia il nuovo contenuto. Usa polite per la stragrande maggioranza degli aggiornamenti dinamici. Riserva assertive solo ai guasti critici — un errore di pagamento, un avviso di scadenza della sessione — in cui l’informazione è tanto urgente da giustificare l’interruzione dell’utente.

Ruoli scorciatoia per le regioni live

Due ruoli racchiudono la semantica di aria-live in un unico attributo:

• role="status" — equivalente ad aria-live="polite". Usalo per messaggi di conferma, stati di caricamento e aggiornamenti non urgenti.
• role="alert" — equivalente ad aria-live="assertive" e implica anche aria-atomic="true". Usalo per i messaggi di errore e i guasti critici.

<!-- Errore annunciato immediatamente, interrompendo la lettura in corso -->
<div role="alert" id="payment-error"></div>

<!-- Aggiornamento di stato annunciato con garbo dopo la lettura in corso -->
<div role="status" id="cart-count">3 articoli nel carrello</div>

Errori comuni con le regioni live

Aggiungere il contenuto prima che l’elemento sia nel DOM. Il browser registra la regione live quando l’elemento viene analizzato per la prima volta. Se inserisci l’elemento e ne imposti il testo contemporaneamente, alcuni screen reader perdono del tutto l’annuncio. Includi sempre il contenitore della regione live nell’HTML iniziale e aggiornane il contenuto tramite JavaScript in un secondo momento.

Usare assertive per tutto. Le regioni live assertive interrompono qualsiasi cosa l’utente stia facendo, inclusi altri annunci. Un contatore di risultati di ricerca che si aggiorna mentre l’utente digita non giustifica un role="alert". L’uso eccessivo di assertive produce un’esperienza ostile per gli utenti di screen reader.

Aggiornare la regione live troppo di frequente. Se un indicatore di avanzamento aggiorna la propria regione live ogni 100 millisecondi, la coda di lettura va in sovraccarico e gli utenti non sentono nulla di utile. Aggiorna il testo live solo in corrispondenza di traguardi significativi — 25%, 50%, 75%, completato — oppure applica un debounce agli aggiornamenti con un timer.

Dimenticare aria-atomic. Per impostazione predefinita viene annunciato solo il nodo di testo modificato all’interno di una regione live. Se vuoi che venga riletta l’intera regione (non solo il frammento modificato), aggiungi aria-atomic="true":

<div aria-live="polite" aria-atomic="true">
  <span id="count">2</span> elementi rimanenti
</div>

Senza aria-atomic, uno screen reader potrebbe annunciare solo “2” quando il contatore passa da 3 a 2. Con l’attributo viene pronunciata la frase completa “2 elementi rimanenti”, che è quasi sempre ciò che si desidera.

Altri attributi ARIA essenziali

aria-label — fornisce un nome accessibile quando nessun testo visibile è appropriato:

<button aria-label="Chiudi la finestra di dialogo">✕</button>

aria-labelledby — rimanda a un altro elemento il cui testo funge da nome accessibile. Da preferire ad aria-label quando il testo dell’etichetta è già visibile nella pagina:

<h2 id="billing-heading">Indirizzo di fatturazione</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — rimanda a un testo supplementare che descrive un elemento oltre al suo nome:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Deve contenere almeno 12 caratteri e includere un simbolo.</p>

aria-expanded — indica se un elemento comprimibile (menu a discesa, fisarmonica, menu) è aperto o chiuso. Aggiornalo in JavaScript ogni volta che lo stato cambia:

<button aria-expanded="false" aria-controls="nav-menu">Menu</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — rimuove un elemento dall’albero dell’accessibilità. Usalo per icone decorative, testo duplicato o elementi visivi che aggiungerebbero solo rumore per gli utenti di screen reader:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 stelle su 5</span>

aria-disabled="true" — contrassegna un controllo come disattivato senza rimuoverlo dall’ordine di focus. Utile quando vuoi che gli utenti scoprano che il controllo esiste e capiscano perché non è disponibile, invece che venga saltato silenziosamente:

<button aria-disabled="true">Invia (compila prima tutti i campi)</button>

Testare ARIA nella pratica

Scrivere attributi ARIA è semplice. Farlo bene richiede di testarli. Gli scanner automatici intercettano i pattern palesemente sbagliati — un role="button" senza nome accessibile, un aria-labelledby che rimanda a un ID inesistente, una regione live con un valore aria-live non valido. Non possono però dirti se il testo annunciato ha senso nel contesto, né se un widget personalizzato complesso si comporta correttamente quando lo si naviga con la sola tastiera.

Per test realistici, usa almeno due combinazioni di screen reader e browser:

• NVDA + Chrome su Windows — gratuito, molto diffuso, vicino alla reale composizione dell’utenza degli screen reader
• VoiceOver + Safari su macOS o iOS — integrato, essenziale per i test di accessibilità su mobile
• JAWS + Chrome o Edge su Windows — a pagamento, ma è lo screen reader più usato negli ambienti aziendali

Naviga i tuoi componenti interattivi usando solo la tastiera. Ascolta con attenzione ciò che viene annunciato quando apri un menu, invii un modulo con un errore di validazione o attivi l’aggiornamento di una regione live. Se l’annuncio è ambiguo o fuorviante, l’implementazione ARIA è sbagliata — a prescindere da ciò che riporta qualsiasi strumento automatico.

La regola che copre tutto

La specifica ARIA include cinque regole di scrittura. La prima è la più importante:

Se puoi usare un elemento o un attributo HTML nativo che integri già la semantica e il comportamento di cui hai bisogno, invece di riutilizzare un elemento e aggiungervi un ruolo, uno stato o una proprietà ARIA per renderlo accessibile, allora fallo.

Costruisci con HTML semantico. Ricorri ad ARIA solo quando l’HTML non basta più. Testa con uno screen reader reale. Questo copre quasi tutte le situazioni che ti troverai ad affrontare.

Per una verifica concreta di come gli attributi ARIA sono implementati sul tuo sito, i nostri audit manuali di accessibilità comprendono test con screen reader condotti da persone che usano quotidianamente le tecnologie assistive e sanno individuare i problemi ARIA più sottili che gli strumenti automatici non rilevano.