ARIA Roles Labels e Landmark — Quando Usarli per un Sito Accessibile (e Come Farlo Bene)

Il tuo sito funziona alla perfezione su Chrome, ma uno screen reader lo interpreta come un muro di gesso. Nessuna struttura, nessun punto di riferimento. I tuoi utenti ipovedenti o non vedenti si perdono — e tu perdi clienti.

Noi, di Meteora Web, lavoriamo ogni giorno con sviluppatori e PMI che scoprono solo dopo il lancio che il sito è inaccessibile. E quando arriva una diffida per mancata conformità WCAG, i costi lievitano. ARIA (Accessible Rich Internet Applications) è uno degli strumenti più potenti per risolvere questo problema — ma usato male fa più danni che benefici.

Questa guida ti spiega quando e come usare ARIA roles, labels e landmark per rendere il tuo sito davvero accessibile, senza trucchi. Partiamo dal concreto.

Cosa sono ARIA roles, labels e landmark e perché sono importanti per l'accessibilità?

ARIA è un insieme di attributi HTML che arricchiscono il significato semantico degli elementi per le tecnologie assistive (screen reader, lettori braille, comandi vocali). I tre pilastri sono:

• Roles: definiscono il tipo di elemento (es. role="button", role="navigation").
• Labels: forniscono un nome accessibile a elementi che altrimenti sarebbero anonimi (es. aria-label su un pulsante icona).
• Landmark: sono ruoli specifici che marcano le regioni principali di una pagina (banner, navigation, main, contentinfo ecc.), permettendo agli utenti di saltare da una sezione all'altra.

Perché sono importanti? Perché l'HTML da solo non basta. Un <div> con un gestore click è un pulsante solo per chi vede il cursore. Uno screen reader lo legge come "div". Aggiungendo role="button" e aria-label="Cerca", diventa un elemento interattivo con nome.

Immagina di entrare in un ufficio senza cartelli: ogni porta è uguale. I landmark sono i cartelli che dicono "Ufficio del personale", "Bagni", "Uscita". Senza, l'utente brancola nel buio.

Operativo: verifica se la tua pagina usa landmark

Apri la pagina in Chrome, apri gli strumenti sviluppatore (F12), vai alla scheda "Accessibility" e guarda il pannello "Accessibility Tree". Se vedi solo generic o region senza nome, sei a terra. Oppure usa il tool WAVE Evaluation Tool: segnala subito la mancanza di landmark.

Quando usare ARIA roles — e quando invece evitarlo?

La regola d'oro viene dal W3C: Non usare ARIA se puoi usare un elemento HTML nativo. Un <button> ha già implicitamente role="button", comportamenti da tastiera e focus nativi. Scrivere <div role="button"> significa dover gestire manualmente eventi, stato, focus. Più codice, più bug, più costi.

Quindi quando usare ARIA roles?

• Quando devi creare un componente personalizzato (un menu a tendina, un carousel, una tab) che non ha un equivalente HTML nativo.
• Quando vuoi modificare la semantica di un elemento esistente (es. <a> usato come pulsante senza href).
• Quando devi aggiungere un ruolo landmark a un contenitore generico (<div role="navigation">).

Errore comune: aggiungere role="banner" a un <header> già implicito. Inutile e ridondante. Lascia che l'HTML nativo faccia il suo lavoro.

Operativo: quando sei tentato di usare ARIA, chiediti: esiste un tag HTML per questo?

Se la risposta è sì (<header>, <nav>, <main>, <footer>, <button>, <input>), usa quello. ARIA è solo per i casi in cui l'HTML non basta.

Come implementare correttamente i landmark ARIA in una pagina?

I landmark sono i ruoli che definiscono le macro-regioni. I più comuni:

• banner — intestazione del sito (solitamente <header>)
• navigation — menu di navigazione (<nav>)
• main — contenuto principale (<main>)
• complementary — contenuto correlato (sidebar, <aside>)
• contentinfo — footer (<footer>)
• search — funzione di ricerca
• form — modulo (usare con cautela, meglio <form aria-label="...">)

Usa gli elementi HTML nativi che hanno già il ruolo implicito. Se per esigenze di layout devi usare <div>, aggiungi role e, se necessario, aria-label per distinguere due regioni dello stesso tipo (es. due nav diverse: una principale, una di servizio).

Esempio: una struttura base con landmark

<body>
  <header role="banner">
    <h1>Meteora Web</h1>
  </header>
  <nav aria-label="Navigazione principale">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/servizi">Servizi</a></li>
    </ul>
  </nav>
  <main>
    <article>...</article>
  </main>
  <aside role="complementary" aria-label="Articoli correlati">
    ...
  </aside>
  <footer role="contentinfo">
    <p>&copy; 2026 Meteora Web</p>
  </footer>
</body>

Attenzione: non mischiare due role sullo stesso elemento. Un <header> non può essere anche navigation. Usa figli annidati.

Come associare label e descrizione a elementi non testuali con ARIA?

Gli attributi aria-label, aria-labelledby e aria-describedby danno un nome o una descrizione a un elemento che altrimenti sarebbe anonimo. Esempi concreti:

• Un pulsante con solo icona: <button aria-label="Menu">&#9776;</button>
• Un campo input senza <label> visibile: <input aria-label="Cerca nel sito" type="search">
• Un iframe che incorpora un video: <iframe title="Video tutorial ARIA" src="..." aria-label="Spiegazione di ARIA roles"></iframe> (meglio usare title nativo)

Differenza tra label e description: il label è il nome breve e univoco; la descrizione fornisce informazioni aggiuntive. Esempio: un pulsante "Acquista" può avere descrizione "Aggiunge al carrello e procede al checkout" associata via aria-describedby.

Operativo: verifica le label con uno screen reader

Prova NVDA (gratuito su Windows) o VoiceOver (su Mac) e naviga tabulando. Ogni elemento interattivo deve annunciare un nome. Se senti solo "Pulsante" senza contesto, manca un aria-label.

Quali sono gli errori comuni con ARIA e come evitarli?

Abbiamo visto decine di siti con questi errori. Ecco i peggiori:

• ARIA roles ridondanti: <button role="button"> — completamente inutile.
• Landmark mancanti o sovrapposti: due role="navigation" senza nomi distinti. Lo screen reader li elenca come "Navigazione", senza differenziarli. Usa aria-label su ciascuno.
• Focus management assente: Aggiungi tabindex="0" agli elementi con ruolo interattivo e gestisci la navigazione da tastiera. ARIA non fa magie: devi programmare il comportamento.
• Attributi dichiarati ma non supportati: alcuni ruoli richiedono proprietà specifiche (aria-expanded, aria-pressed). Se non le imposti, lo screen reader annuncia uno stato sbagliato.
• Non testare con utenti reali: strumenti automatici (WAVE, axe) trovano errori tecnici, ma solo un test con utenti ipovedenti svela problemi di usabilità.

Operativo: esegui un audit rapido con axe DevTools

Installa l'estensione axe DevTools su Chrome, apri la tua pagina e lancia un audit. Filtra per "ARIA". Risolvi ogni issue segnalato, partendo da quelli critici. Dopo ogni modifica, ripeti il test.

Cosa fare adesso per rendere il tuo sito conforme WCAG con ARIA

Non serve rifare tutto da capo. Segui questa checklist operativa per ogni pagina del tuo sito (parti dalla home e dalle pagine più visitate):

1. Identifica le macro-regioni (header, nav, main, aside, footer) e assegna il landmark corretto — meglio con tag HTML nativi.
2. Nomina ogni landmark con aria-label se ne hai due dello stesso tipo (es. due navigazioni).
3. Controlla che tutti i pulsanti e link abbiano un nome accessibile: se usano icone, aggiungi aria-label.
4. Verifica che i moduli abbiano label esplicite (<label> o aria-label per ogni input).
5. Rimuovi ARIA ridondante: cancella role su elementi nativi come <header>, <nav>, <main>, <button>.
6. Testa con NVDA o VoiceOver navigando solo da tastiera (Tab, Shift+Tab, frecce).
7. Documenta le scelte: se hai usato ruoli personalizzati, lascia commenti nel codice per i futuri sviluppatori.

Noi di Meteora Web lo facciamo per ogni progetto che seguiamo, dal dominio al fatturato. Non è solo compliance: è rispetto per i tuoi utenti e un investimento che paga in termini di reach, reputazione e riduzione del rischio legale.

Se vuoi approfondire, leggi la nostra guida pillar sull'accessibilità web WCAG.

Per risorse ufficiali: consulta le ARIA Authoring Practices del W3C e il MDN ARIA reference.