I lettori di schermo e la prima regola di ARIA

La prima regola di ARIA è evitarla: se un elemento HTML nativo, come button, fa già il lavoro, usa quello invece di aggiungere un role a un div.

Da che cosa parte un lettore di schermo

Un lettore di schermo non legge i pixel. Il browser costruisce dall'HTML un albero di accessibilità, una copia semplificata della pagina in cui ogni elemento che conta ha un ruolo (pulsante, link, titolo, casella di controllo), un nome (il testo che lo identifica) e a volte uno stato (selezionato, espanso, disattivato). Il lettore di schermo legge ad alta voce quell'albero o lo invia a un display braille. Il criterio di successo 4.1.2 Nome, ruolo, valore delle WCAG 2.2, di livello A, chiede che ogni controllo della pagina esponga queste tre cose.

Chi ascolta raramente segue una pagina dall'inizio alla fine. I lettori di schermo integrati nei principali sistemi operativi, e quelli gratuiti che si possono installare, permettono di aprire un elenco di titoli, link o punti di riferimento, di saltare al campo successivo del modulo o di leggere una riga alla volta. Ecco perché le unità precedenti contano tanto: titoli veri, campi con etichetta, pulsanti che sono davvero pulsanti e testo alternativo finiscono tutti direttamente in quell'albero. Conta anche l'attributo lang sull'elemento html. Il criterio 3.1.1 Lingua della pagina lo richiede, e i lettori di schermo lo usano per scegliere la voce e la pronuncia giuste.

Che cosa aggiunge ARIA

WAI-ARIA (Accessible Rich Internet Applications) è un insieme di attributi che cambiano che cosa entra nell'albero di accessibilità: role imposta il ruolo, attributi come aria-label impostano il nome, e altri come aria-checked o aria-expanded impostano lo stato. ARIA cambia solo ciò che viene annunciato. Non rende un elemento raggiungibile con il focus, non aggiunge comportamenti da tastiera e non cambia il suo aspetto. La guida W3C ARIA Authoring Practices lo dice in un titolo: «No ARIA is better than bad ARIA» (meglio niente ARIA che un ARIA sbagliato). Un ARIA sbagliato dice a chi usa un lettore di schermo qualcosa di falso sulla pagina.

Le regole d'uso di ARIA

Il documento W3C Using ARIA fissa alcune regole brevi che vengono citate ovunque (nel febbraio 2026 è stato segnato come bozza interrotta, ma le regole non sono cambiate). Regola 1: se puoi usare un elemento o un attributo HTML nativo che ha già il significato e il comportamento che ti servono, usalo, invece di riadattare un altro elemento con ARIA. Regola 2: non cambiare la semantica nativa se non è davvero necessario. Regola 3: ogni controllo interattivo ARIA deve essere usabile con la tastiera. Regola 4: non mettere role="presentation" o aria-hidden="true" su un elemento che può ricevere il focus, altrimenti alcuni utenti arriveranno su «niente».

ARIA aiuta davvero quando colma lacune che l'HTML non può colmare. Un pulsante che contiene solo un'icona non ha testo, quindi non ha un nome; aria-label="Close" gliene dà uno. Un'icona SVG accanto a un testo visibile è decorazione, e aria-hidden="true" sull'svg la tiene fuori dall'albero. Sono i due attributi che servono alla maggior parte dei principianti. Per widget interi come schede o menu, segui il modello corrispondente della guida Authoring Practices invece di inventarne uno.