:no_upscale():format(png))
Gruppo VéGé sceglie Eye-Able come partner tecnologico per un ecosistema digitale più equo e vicino alle persone
Leggi la storia![]()
Immaginate di visitare un negozio online e di vedere solo l'icona del carrello. Gli utenti vedenti capiscono immediatamente la funzione di acquisto. Ma per gli utenti che si affidano ai lettori di schermo, il pulsante rimane poco chiaro. Solo con un'etichetta ARIA come "Aggiungi al carrello" diventa chiaramente descritto e accessibile.
L'accessibilità digitale inizia dal codice. L'HTML semantico ne costituisce il fondamento, mentre l'interfaccia aria-label interviene solo laddove gli elementi standard non sono sufficienti. Questo non avvantaggia solo le istituzioni, ma anche le aziende, in particolare i negozi online, dove pulsanti e campi modulo chiari garantiscono un processo di ordinazione fluido.
L'attributo aria-label fa parte della specifica ARIA (Accessible Rich Internet Applications) del W3C (World Wide Web Consortium). Il W3C è l'organismo internazionale che sviluppa standard web aperti, tra cui Linee guida per l'accessibilità dei contenuti web (WCAG) .
aria-label aggiunge etichette invisibili agli elementi HTML, che i lettori di schermo annunciano quando le etichette visibili mancano o non sono chiare. Questo colma il divario tra design e accessibilità tecnica, rendendo le interfacce comprensibili a tutti.
Gli attributi ARIA sono stati sviluppati per garantire l'accessibilità laddove l'HTML raggiunge i suoi limiti. I siti web moderni con contenuti dinamici, come elementi JavaScript, widget personalizzati o design visivi complessi, presentano sfide specifiche. In questi casi, un attributo ARIA come aria-label garantisce che anche queste interfacce vengano interpretate correttamente dai lettori di schermo.
Una differenza fondamentale tra le etichette aria e le etichette visibili risiede nel pubblico di riferimento: le etichette visibili sono disponibili per tutti gli utenti, mentre le etichette aria sono destinate esclusivamente alle tecnologie assistive.
Le etichette visibili sono le descrizioni testuali standard visualizzate nell'interfaccia, ad esempio il testo "Indirizzo e-mail" sopra o accanto a un campo di input:
<label for="email">Indirizzo email</label>
<input type="email" id="email" name="email">
Tutti gli utenti riconoscono immediatamente cosa inserire nel campo e anche i lettori di schermo leggono il testo ad alta voce. Se manca un'etichetta visibile, è possibile utilizzare un'etichetta aria. Questa aggiunge in modo invisibile una descrizione che solo i lettori di schermo possono rilevare:
<input type="email" id="email" name="email" aria-label="Indirizzo email">
In questo modo, il campo rimane comprensibile e accessibile, anche senza un'etichetta visibile.

I lettori di schermo determinano il nome accessibile di un elemento secondo un ordine prestabilito:
aria-labelledby – fa riferimento al testo visibile nel codice
etichetta aria – etichetta invisibile
visibile <etichetta> – per i campi del modulo
contenuti testuali – ad esempio, testo del pulsante
attributo titolo – ultima risorsa
Un pulsante con l'icona di ricerca non viene riconosciuto senza una descrizione aggiuntiva. Con aria-label="Cerca" , il lettore di schermo legge ad alta voce “Cerca”, in modo chiaro e comprensibile.
Esempio:
Un pulsante con l'icona di una lente d'ingrandimento per la ricerca non ha testo visibile. Senza informazioni aggiuntive, sarebbe privo di significato per i lettori di schermo. Tuttavia, se aggiungi aria-label="Cerca" , il lettore di schermo annuncia "Cerca" e ignora tutte le altre possibili fonti.
Un caso d'uso comune per aria-label è rappresentato dai pulsanti che contengono solo un'icona. Per gli utenti vedenti, una lente d'ingrandimento è immediatamente comprensibile come funzione di ricerca, ma per i lettori di schermo non ha alcun significato. Con aria-label, il pulsante diventa comprensibile anche per le tecnologie assistive:
<button aria-label="Avvia ricerca">
<svg aria-hidden="true" width="24" height="24">…</svg>
</button>
Un altro esempio pratico sono gli elenchi. Molti negozi online utilizzano elenchi basati su icone, come gli elenchi di categorie con simboli. Gli screen reader annuncerebbero solo "Elenco con 5 elementi". Con aria-label="Categorie di prodotto" , diventa chiaro cosa contiene la lista.
I link, a loro volta, dovrebbero descrivere chiaramente la pagina a cui conducono. Una frase vaga come "Scopri di più" non è accessibile, perché rimane poco chiara senza contesto. L'elemento aria-label può migliorare questo aspetto:
<a href="/articolo/accessibilità"
aria-label="Leggi l'articolo sull'accessibilità digitale">
Leggi l'articolo sull'accessibilità digitale
</a>
I moduli sono una parte fondamentale di quasi ogni sito web. Per renderli accessibili, ogni campo del modulo dovrebbe avere un nome chiaro. Normalmente questo viene fatto con un elemento visibile <etichetta> elemento:
<label for="email">Indirizzo email</label>
<input type="email" id="email" name="email">
Il vantaggio: Tutti gli utenti visualizzano l'etichetta "Indirizzo e-mail" e i lettori di schermo la leggono ad alta voce. Inoltre, gli utenti possono fare clic sull'etichetta per selezionare automaticamente il campo.
A volte, per ragioni di design, non viene utilizzata alcuna etichetta visibile, ad esempio quando all'interno del campo compare solo un segnaposto. Per gli utenti di screen reader, questo rappresenta un problema, poiché i segnaposto non vengono considerati etichette ufficiali. È qui che interviene aria-label:
<input type="email"
aria-label="Indirizzo email"
placeholder="example@domain.com">
Gli utenti vedenti visualizzano il campo come di consueto, mentre gli utenti di screen reader sentono "Indirizzo email". Ciò garantisce che il campo rimanga comprensibile anche in assenza di un'etichetta visibile.
Un altro esempio sono i campi di input che richiedono istruzioni aggiuntive —come i campi password. Qui, una semplice etichetta non basta. Con aria-descritta da Il campo può essere collegato a ulteriori informazioni:
<input type="password"
aria-label="Password"
aria-describedby="pwd-help">
<div id="pwd-help">Almeno 8 caratteri, incluso un numero</div>
In questo caso, il lettore di schermo legge prima "Password", seguito da "Almeno 8 caratteri, incluso un numero".
Importante: l'etichetta aria nei moduli dovrebbe generalmente rimanere la eccezione . Un visibile <etichetta> è quasi sempre la soluzione migliore: è chiara a tutti, più facile da usare e richiede meno logica aggiuntiva. aria-label dovrebbe servire principalmente come soluzione di ripiego quando le etichette sono nascoste per motivi di design o di layout.
I ruoli ARIA descrivono la funzione di un elemento, mentre l'etichetta aria ne definisce il nome. Questa combinazione è particolarmente importante per i widget personalizzati che vanno oltre la semantica standard dell'HTML:
<div role="button" aria-label="Iscriviti alla newsletter" tabindex="0">
<svg>...</svg>
Iscrizione
</div>
Per i widget interattivi come i menu, sono rilevanti attributi aggiuntivi. aria-expanded indica se un menu è espanso, mentre aria-haspopup Segnali che indicano che un elemento attiva un popup o un menu:
<button aria-label="Apri il menu principale"
aria-expanded="false"
aria-haspopup="true"
aria-controls="main-menu">
☰
</button>
<ul id="main-menu" role="menu" hidden>
<li role="menuitem"><a href="#home">Home</a></li>
<li role="menuitem"><a href="#about">Chi siamo</a></li>
</ul>
Tuttavia, si applica la prima regola di ARIA: Utilizzare HTML nativo ogni qualvolta sia possibile. Un vero <pulsante> l'elemento è sempre preferibile a un <div role="button"> , poiché include già tutte le funzionalità richieste.

Un errore comune è confondere l'etichetta aria con il testo alternativo. Entrambi servono per l'accessibilità, ma hanno scopi diversi:
Testo alternativo È specifico per le immagini e descrive il contenuto visivo. Appare quando l'immagine non può essere caricata e viene letto ad alta voce dai lettori di schermo.
etichetta aria D'altra parte, può essere applicato a quasi tutti gli elementi HTML e fornisce ai lettori di schermo informazioni aggiuntive sulla funzione o sul significato di un elemento.
<!-- Corretto: Testo alternativo per le immagini -->
<img src="product.jpg"
alt="Laptop con schermo aperto">
<!-- Corretto: aria-label per il pulsante senza testo -->
<button aria-label="Aggiungi al carrello">
<svg aria-hidden="true">...</svg>
</button>
Per le immagini, il calcolo del nome accessibile segue una gerarchia: aria-labelledby sovrascritture etichetta aria , che a sua volta sovrascrive il alt attributo. Ma usando aria-label="Testo alternativo" invece di un alt L'attributo non è consigliato. alt dovrebbe essere sempre la prima scelta per la grafica.
Quando si utilizzano icone SVG, è necessaria particolare attenzione:
Icone decorative dovrebbe essere nascosto ai lettori di schermo con aria-hidden="true" .
Icone funzionali serve un'etichetta aria significativa.
L'utilizzo efficace di aria-label segue linee guida precise per garantire sia l'accessibilità che la manutenibilità del codice. Gli sviluppatori dovrebbero tenere a mente diversi fattori per evitare confusione agli utenti:
Utilizzare l'etichetta aria con parsimonia: Applicalo solo quando gli elementi HTML nativi o le etichette visibili non sono sufficienti. Gli elementi che hanno già un nome descrittivo tramite contenuto testuale o attributi non necessitano di un'etichetta aria aggiuntiva.
Scrivi descrizioni chiare e concise: L'etichetta aria deve essere autoesplicativa e descrivere accuratamente lo scopo dell'elemento. Evitare termini tecnici o nomi interni che non siano comprensibili agli utenti finali.
Combinare con HTML semantico: ARIA integra HTML ma non lo sostituisce. Utilizza elementi semantici come <pulsante> , <nav> , O <principale> come base e, se necessario, estenderli con attributi ARIA.
<!-- SBAGLIATO: etichetta aria ridondante -->
<button aria-label="Accedi">Accedi</button>
<!-- DESTRA: nessuna etichetta aria necessaria -->
<button>Accedi</button>
Prendi in considerazione la gestione della concentrazione: Per i widget interattivi, è fondamentale gestire correttamente il focus. I popup e le finestre di dialogo devono impostare il focus iniziale sul primo elemento selezionabile e restituirlo all'elemento che li ha attivati alla chiusura.
Gli errori di implementazione più frequenti derivano da una scarsa comprensione della gerarchia ARIA e da un utilizzo scorretto:
Etichette contrastanti: Se l'etichetta aria-label non corrisponde al testo visibile, gli utenti del software di input vocale si confondono. Ad esempio, una persona vede "Vorname" come etichetta, ma lo screen reader annuncia "First Name". Di conseguenza, i comandi vocali non funzionano.
Uso eccessivo di ARIA: Aggiungere l'attributo aria-label a ogni elemento riduce l'accessibilità. Gli utenti di screen reader vengono sovraccaricati di informazioni ridondanti anziché raggiungere più rapidamente il loro obiettivo.
Impossibile aggiornare i contenuti dinamici: Per gli elementi gestiti tramite JavaScript, è necessario garantire che i valori di aria-label vengano aggiornati al variare dello stato. Ciò è particolarmente importante per i widget con stati dinamici.
Etichette imprecise: Le etichette che non rispecchiano più la funzione attuale dell'elemento creano false aspettative e rendono più difficile la navigazione.
Verificare la necessità: L'elemento necessita davvero di un'etichetta aria-label, oppure è sufficiente l'HTML semantico?
Test con lettori di schermo: Per la verifica, utilizzare NVDA (Windows), VoiceOver (Mac) o altri screen reader.
Convalidare il calcolo del nome accessibile: Utilizza gli strumenti per sviluppatori del browser per verificare quale nome viene effettivamente calcolato.
Garantire la coerenza: Utilizza una terminologia coerente per elementi simili in tutto il sito web.
Documentare le implementazioni di ARIA: Spiega nel codice perché e come vengono utilizzati gli attributi ARIA.
Considera tutti i metodi di input: Assicurati che i widget siano utilizzabili sia tramite tastiera che tramite tocco.
Rivedi gli elenchi e la navigazione: Utilizza tag HTML semantici per elenchi e link di navigazione, aggiungendo attributi ARIA ove necessario.
L'attributo aria-label è uno strumento prezioso per i siti web accessibili, ma richiede un'implementazione ponderata. Colma il divario tra design visivo e accessibilità semantica, ma dovrebbe sempre essere considerato un complemento all'HTML semantico, non un sostituto.
L'efficacia di aria-label è particolarmente evidente nei pulsanti con icone, nei widget personalizzati e nei casi in cui le etichette visibili comprometterebbero l'aspetto grafico. Allo stesso tempo, i requisiti legali, come BFSG e WCAG 2.1, impongono un approccio sistematico alle etichette ARIA.
La chiave per una corretta implementazione di ARIA risiede nella comprensione del fatto che l'accessibilità web rappresenta un passo importante verso l'inclusione digitale per tutte le persone, indipendentemente dalle loro capacità o limitazioni individuali.
L'attributo aria-label dovrebbe essere applicato solo quando gli elementi HTML nativi o le etichette visibili non sono sufficienti. Un uso eccessivo comporta informazioni ridondanti e un'esperienza utente peggiore per gli utenti di screen reader.
Per test realistici, utilizza screen reader come NVDA (Windows) o VoiceOver (Mac/iOS). Gli strumenti per sviluppatori del browser mostrano le proprietà calcolate e il nome accessibile effettivo nella scheda Accessibilità.
I moderni screen reader come NVDA, JAWS, VoiceOver e TalkBack offrono un ampio supporto per aria-label. Tuttavia, la compatibilità può variare a seconda del browser e della versione, pertanto si consiglia di effettuare dei test su diverse configurazioni.
I lettori di schermo utilizzano il nome successivo disponibile nella gerarchia di calcolo dei nomi accessibili: aria-labelledby, contenuto testuale visibile o l'attributo title. Senza alcuna etichetta, gli elementi interattivi potrebbero rimanere incomprensibili alle tecnologie assistive.
L'accessibilità inizia dal codice: con Eye-Able, puoi verificare la presenza di etichette ARIA corrette e altre barriere nei tuoi siti web e nelle tue applicazioni, in modo legale ed efficiente.
:no_upscale():format(png))
Gruppo VéGé sceglie Eye-Able come partner tecnologico per un ecosistema digitale più equo e vicino alle persone
Leggi la storia:no_upscale():format(png))
Iperal sceglie Eye-Able® per costruire un digitale senza barriere.
Leggi la storia:no_upscale())
L’accessibilità parte dal file di design: arriva il plugin Eye-Able per Figma
Leggi la storia:no_upscale())
Accessibilità digitale: il 2026 sarà l'anno dei controlli
Leggi la storiaContact us and we will be happy to help you.
:no_upscale():format(png))