Se hai un sito con un minimo di interazione, un menu che si apre, una tab che cambia contenuto, una finestra che compare sopra il resto, prima o poi qualcuno ti ha detto che serve ARIA. Magari te l’ha scritto un tool di validazione, magari un consulente, magari l’hai letto tu stesso mentre cercavi di capire perché il sito non passava un controllo di accessibilità. Così hai aggiunto attributi. Un role qua, un aria-label là, un aria-hidden dove sembrava sensato. Il tool ha smesso di lamentarsi e la cosa è finita lì.
ARIA è uno strumento delicato. Nei casi giusti risolve problemi che l’HTML da solo non sa affrontare. Negli altri fa danni silenziosi. Il sito ti sembra identico, ma l’esperienza di chi lo naviga con uno screen reader cambia… in negativo.
Vuoi dormire sul velluto? Leggi la guida per capire un po’ meglio di che si tratta.
Cos’è e cosa fa ARIA
ARIA è una specifica del W3C, sviluppata dal ramo che si occupa di accessibilità, la Web Accessibility Initiative. Da lì il nome per esteso, WAI-ARIA, anche se nell’uso quotidiano tutti la chiamano solo ARIA. Vive dentro il lavoro più ampio sull’accessibilità del web, quello che in Europa oggi ha anche un peso normativo preciso con lo European Accessibility Act, e serve a coprire un buco che l’HTML da solo lascia aperto.
L’HTML ha un vocabolario semantico limitato. Sa dire “questo è un titolo”, “questo è un campo di testo”, “questo è un pulsante”, e per ognuna di queste cose lo screen reader sa già cosa annunciare all’utente. Ma quando costruisci qualcosa che l’HTML non prevede, un carosello, un menu a più livelli, un pannello che si aggiorna senza ricaricare la pagina, quel vocabolario finisce. Lo screen reader vede un ammasso di div e span e non ha idea di cosa siano, né di come annunciarli.
ARIA riempie quel vuoto aggiungendo informazioni che le tecnologie assistive sanno leggere. Lo fa con tre tipi di attributi. I ruoli dicono cosa è un elemento: role="dialog" segnala che quel blocco è una finestra di dialogo, role="tablist" che quella fila di voci è un set di schede. Gli stati dicono in che condizione si trova adesso: aria-expanded="false" racconta che un menu è chiuso, aria-checked="true" che una casella è spuntata. Le proprietà aggiungono relazioni e dettagli stabili, come aria-label che dà un nome a un elemento che altrimenti non ne avrebbe, o aria-describedby che lo collega a un testo di supporto.
Una cosa che ARIA non fa è cambiare il comportamento. Un role="button" su un div dice allo screen reader “trattalo come un pulsante”, ma non rende quel div un pulsante. Non gli dà il focus da tastiera, non lo fa reagire alla barra spaziatrice, non gli aggiunge nessuna delle cose che un vero <button> si porta dietro da solo. Hai promesso all’utente un pulsante e gli hai consegnato un div travestito. Dal punto di vista di chi naviga a tastiera, gli hai mentito con un attributo in più.
La prima regola di ARIA è… non usare ARIA
Suona come una battuta e invece è la raccomandazione ufficiale del W3C, scritta nero su bianco nelle linee guida. Se esiste un elemento HTML nativo che fa quello che ti serve, usi quello e ARIA lo lasci stare. Un <button> vero batte sempre un <div role="button">. Il pulsante nativo arriva già completo: lo raggiungi con il tab, risponde a invio e barra spaziatrice, comunica il suo stato alle tecnologie assistive. Tutto questo senza che tu scriva una riga in più.
Il dato che rende il tutto molto reale e concreto arriva dall’analisi di WebAIM, che ogni anno analizza il codice del milione di homepage più visitate al mondo. Il loro rilevamento più recente dimostra una cosa davvero poco lusinghiera: le pagine che usano ARIA hanno in media più errori di accessibilità di quelle che non lo usano affatto.
ARIA non c’entra. A fare danni è l’applicarlo a caso, per riflesso, da parte di chi ha imparato che “aggiungere ARIA fa accessibilità” senza la seconda metà della frase, quella in cui aggiungerlo male fa il contrario.
Quando usare ARIA?
Detto tutto questo, ci sono situazioni in cui ARIA diventa l’unica strada percorribile. Sono i casi in cui costruisci qualcosa che l’HTML, per quanto ci provi, non sa descrivere da solo.
Pensa a un sistema di schede, in cui clicchi su una linguetta e cambia il contenuto sotto senza che la pagina si ricarichi. In HTML non esiste un elemento “scheda”. Esistono link, bottoni, contenitori. Con quelli puoi costruire l’aspetto e il comportamento, ma per uno screen reader resta un insieme di pezzi scollegati. Qui ARIA fa il lavoro che nient’altro può fare: role="tablist", role="tab" e role="tabpanel" dicono all’utente che quelle voci sono schede, che sono collegate ai pannelli sotto, e aria-selected racconta quale è attiva in quel momento.
Lo stesso vale per una finestra modale, quel riquadro che compare sopra il resto e blocca l’interazione con la pagina sottostante finché non lo chiudi. Un role="dialog" insieme ad aria-modal="true" comunica alle tecnologie assistive che adesso il mondo si è ristretto a quel riquadro e che il resto della pagina è temporaneamente fuori gioco. È un’informazione che a schermo dai con un velo grigio dietro il riquadro e che senza ARIA per uno screen reader semplicemente non esiste.
Poi ci sono le live region, forse il caso in cui ARIA mostra meglio la sua ragione d’essere. Sono le zone della pagina che si aggiornano da sole: un messaggio di conferma che appare dopo l’invio di un modulo, un contatore di risultati che cambia mentre filtri, una notifica che compare in un angolo. Chi guarda lo schermo se ne accorge al volo. Chi usa uno screen reader, senza un aria-live che segnali “qui è cambiato qualcosa, annuncialo”, non viene avvisato di niente.
Il filo che tiene insieme questi casi è sempre lo stesso. ARIA serve quando aggiunge un’informazione che non esiste da nessun’altra parte nel codice, non quando ridice con un attributo qualcosa che un elemento nativo già comunicava per conto suo.
Insidie nascoste
Il problema degli errori ARIA è che non si manifestano dove guardi. Un alt mancante su un’immagine, un contrasto troppo debole, quelli in un modo o nell’altro si notano. Un attributo ARIA sbagliato invece lavora sul livello che solo le tecnologie assistive leggono. A schermo non lascia traccia. Il sito passa il collaudo visivo, il cliente lo approva, tutti sono contenti. Intanto però per una fetta di utenti quel sito è diventato più ostico di prima.
Il caso più comune è l’attributo che contraddice quello che l’elemento già dice. Metti un role="button" su un link vero e lo screen reader si trova davanti a un elemento che è insieme link e pulsante, due cose che si comportano in modo diverso. Oppure un aria-label che ribattezza un pulsante che aveva già il suo bravo testo dentro, così l’utente sente un nome mentre chi vede ne legge un altro.
Poi c’è l’aria-hidden piazzato con troppa disinvoltura. Nasce per nascondere alle tecnologie assistive elementi puramente decorativi che a leggerli ad alta voce sarebbero solo rumore e distrazione. Se perlò finisce sopra un contenitore che dentro ha anche roba che serve hai reso invisibile agli screen reader un pezzo di pagina che a schermo è lì. Nessuno se ne accorgerà finché non è un utente reale a sbatterci contro.
C’è un motivo per cui questi errori sono diventati più frequenti e ha a che fare con il modo in cui si costruiscono i siti oggi. Buona parte del codice arriva da framework e librerie di terze parti e una parte crescente la scrivono strumenti automatici o assistenti AI, il cosiddetto vibe coding. Il codice esce che sembra a posto e porta con sé ARIA applicato per riflesso. L’accessibilità di facciata prende il posto di quella vera: tutto compilato, tutto validato, ma sotto un cumulo di attributi che nessuno ha davvero studiato e realizzato con cognizione di causa.
Per chi commissiona un sito la conseguenza è concreta. Un fornitore che ti riempie il codice di ARIA non ti sta necessariamente dando un sito più accessibile. Con lo European Accessibility Act entrato in vigore l’accessibilità è passata da buona pratica a requisito che ti riguarda direttamente.
Usa ARIA con consapevolezza
ARIA è potente per lo stesso motivo per cui è pericoloso: ti lascia dire alle tecnologie assistive cose che l’HTML da solo non direbbe. Proprio per questo ti lascia anche dire cose sbagliate con la stessa facilità. È uno di quegli strumenti che sembrano una manna dal cielo, finché non scopri gli altarini di un’implementazione fatta con troppa leggerezza.
A volte la cosa più accessibile che puoi fare è usare l’elemento nativo e fermarti lì. Chi costruisce siti per mestiere lo sa. Chi te lo vende come “aggiungiamo ARIA per l’accessibilità” spesso no.
