Criteri di successo WCAG · Level A

WCAG 2.5.3: Etichetta nel nome

WCAG 2.5.3 richiede che i componenti interattivi con etichette di testo visibili abbiano un nome accessibile che contenga il testo visibile, garantendo che gli utenti che utilizzano l’input vocale possano attivare i controlli pronunciando ciò che vedono. Le discrepanze tra le etichette visibili e i nomi accessibili interrompono la navigazione tramite controllo vocale e minano la fiducia di milioni di utenti.

  • Level A

Cosa significa questa regola

\n

WCAG 2.5.3 — Label in Name — si applica a qualsiasi componente dell'interfaccia utente che abbia un'etichetta di testo visibile. Il criterio richiede che il nome accessibile di quel componente corrisponda esattamente al testo dell'etichetta visibile oppure contenga almeno il testo dell'etichetta visibile come sottostringa. Questo evita la situazione in cui l'utente vede un'etichetta sullo schermo ma la sua tecnologia assistiva o il software di riconoscimento vocale riconosce un nome completamente diverso dietro le quinte.

\n

Il nome accessibile è il nome esposto all'albero di accessibilità e utilizzato da screen reader, software di controllo vocale e altre tecnologie assistive. Può provenire da varie fonti, tra cui il contenuto testuale visibile dell'elemento, un attributo aria-label, un riferimento aria-labelledby, un attributo title o un elemento <label> associato. Quando uno sviluppatore sovrascrive il nome accessibile con qualcosa che non include il testo dell'etichetta visibile, si verifica una mancata corrispondenza e il criterio non è soddisfatto.

\n

Gli elementi interessati includono qualsiasi componente interattivo che visualizza testo e che ha anche un nome accessibile: pulsanti, link, campi di input dei form con etichette visibili, voci di menu, tab, checkbox, pulsanti di opzione (radio button) e widget ARIA personalizzati. Gli elementi non interattivi come paragrafi o intestazioni non sono coperti da questo criterio.

\n

Cosa è considerato conforme: Il nome accessibile contiene il testo dell'etichetta visibile come sottostringa continua, ignorando gli spazi iniziali e finali. La corrispondenza non distingue tra maiuscole e minuscole. Ad esempio, se un pulsante riporta "Search Products", un nome accessibile "Search Products Now" è conforme perché contiene "Search Products". Un nome accessibile "Find Products" non è conforme perché non contiene il testo visibile.

\n

Cosa è considerato non conforme: Il nome accessibile è completamente diverso dall'etichetta visibile, oppure il nome accessibile omette una parte significativa dell'etichetta visibile. Un pulsante che visivamente riporta "Buy Now" ma ha aria-label='Purchase item' non soddisfa questo criterio. Allo stesso modo, un link che riporta "Contact Us" ma è racchiuso in un elemento con aria-label='Reach our team' non è conforme.

\n

Eccezioni ufficiali definite in WCAG: Il criterio non si applica ai componenti in cui l'etichetta è puramente simbolica o pittografica senza equivalente testuale (ad esempio, un pulsante composto solo da un'icona senza testo visibile). Non si applica nemmeno quando il testo fa parte di un elemento puramente decorativo che non ha significato semantico. Anche la notazione matematica e gli scenari specifici di una lingua in cui la rappresentazione testuale non può essere mappata a una parola pronunciata sono esclusi. Inoltre, i componenti in cui il nome accessibile è intenzionalmente ampliato con contesto aggiuntivo — a condizione che il testo visibile sia comunque presente all'interno del nome accessibile — sono conformi.

\n\n

Perché è importante

\n

Questo criterio tutela principalmente gli utenti che si affidano a software di riconoscimento vocale come Dragon NaturallySpeaking (ora Dragon Professional), Windows Speech Recognition o Voice Control di Apple. Questi utenti navigano e attivano gli elementi dell'interfaccia pronunciando l'etichetta che vedono sullo schermo. Quando il nome accessibile non corrisponde all'etichetta visibile, il software non riesce a trovare l'elemento di destinazione quando l'utente ne pronuncia il nome, rendendo di fatto il controllo irraggiungibile senza mouse o tastiera. Per gli utenti con disabilità motorie — inclusi coloro che hanno lesioni da sforzo ripetitivo, distrofia muscolare, paralisi cerebrale o lesioni al midollo spinale — l'input vocale è spesso il mezzo principale o unico per usare un computer. Una mancata corrispondenza su un singolo pulsante può bloccare l'accesso a un intero flusso di lavoro.

\n

Anche gli utenti di screen reader sono interessati. Quando uno screen reader annuncia un nome accessibile diverso da ciò che è visibile sullo schermo, si crea disorientamento cognitivo. Un utente vedente che utilizza anche uno screen reader — ad esempio, una persona con ipovisione che usa contemporaneamente feedback visivo e uditivo — può sentire una cosa annunciata mentre legge qualcosa di diverso sullo schermo, compromettendo il proprio modello mentale dell'interfaccia.

\n

Gli utenti con disabilità cognitive traggono beneficio dalla coerenza tra ciò che leggono e ciò che viene pronunciato o annunciato. Cambiamenti di nome inattesi aumentano il carico cognitivo e possono causare confusione o errori, in particolare per gli utenti con problemi di memoria o per chi sta imparando a usare un sistema per la prima volta.

\n

Uno scenario concreto nel mondo reale: Si consideri una pagina di checkout di un sito di e-commerce con un pulsante che visualizza il testo "Place Order". Uno sviluppatore aggiunge aria-label='Submit purchase form' per fornire quello che ritiene un nome più descrittivo. Un cliente che usa Dragon NaturallySpeaking dice "Click Place Order" — Dragon analizza l'albero di accessibilità, non trova alcun elemento chiamato "Place Order" e non può attivare il pulsante. Il cliente non può completare l'acquisto senza passare al controllo tramite mouse, cosa che potrebbe non essere in grado di fare. Abbandona la transazione. Questo non è un caso limite ipotetico; è un modello di errore comune riscontrato negli audit automatizzati su siti di retail e banking.

\n

Secondo l'Organizzazione Mondiale della Sanità, oltre un miliardo di persone nel mondo vive con qualche forma di disabilità. Il rapporto WebAIM Million 2023 ha rilevato che le discrepanze nelle etichette rispetto a WCAG 2.5.3 compaiono in una proporzione significativa delle pagine analizzate, spesso introdotte da ARIA ben intenzionata ma applicata in modo errato. Oltre all'accessibilità, una denominazione coerente migliora la SEO perché i crawler dei motori di ricerca che indicizzano il testo di link e pulsanti per il ranking di rilevanza ricevono segnali più significativi quando i nomi accessibili sono allineati con il testo visibile.

\n\n

Regole Axe-core correlate

\n
    \n
  • label-content-name-mismatch: Questa è la principale regola automatizzata associata a WCAG 2.5.3. La regola controlla gli elementi interattivi — come pulsanti, link e ruoli ARIA come role='button', role='link', role='menuitem' e role='tab' — che hanno sia un'etichetta di testo visibile sia un nome accessibile. Segnala qualsiasi elemento in cui il nome accessibile non contiene il testo visibile come sottostringa (senza distinzione tra maiuscole e minuscole). La regola prende di mira in particolare gli elementi in cui il nome accessibile è sovrascritto da aria-label o aria-labelledby in un modo che diverge dal testo sullo schermo. Axe segnala queste situazioni come violazioni con livello di impatto "serious" perché impediscono direttamente agli utenti che usano l'input vocale di attivare i controlli.
  • \n
  • Limitazioni del rilevamento automatico: Strumenti automatici come axe-core possono rilevare in modo affidabile le discrepanze quando il testo visibile è reso come nodi di testo semplice all'interno dell'elemento e il nome accessibile proviene da un attributo statico aria-label o aria-labelledby. Tuttavia, è necessario un test manuale quando: (1) il testo visibile è reso tramite pseudo-elementi CSS ::before o ::after, poiché questi possono essere inclusi o meno nell'albero di accessibilità a seconda della versione del browser e della tecnologia assistiva; (2) l'etichetta è inserita dinamicamente tramite JavaScript dopo il caricamento della pagina; (3) il testo visibile include icone o testo basato su immagini in cui la componente testuale deve essere dedotta; (4) il nome accessibile calcolato dell'elemento coinvolge catene complesse di aria-labelledby che concatenano più elementi. In questi casi, un tester umano che utilizza uno screen reader deve verificare ciò che viene effettivamente annunciato rispetto a ciò che è visibile.
  • \n
\n\n

Come testare

\n
    \n
  1. Scansione automatizzata con axe DevTools o Lighthouse: Installa l'estensione del browser axe DevTools (Chrome o Firefox) oppure esegui un audit di accessibilità Lighthouse in Chrome DevTools. Avvia la scansione sulla pagina completamente renderizzata — assicurati che contenuti dinamici, modali e menu espansi siano aperti se contengono elementi interattivi. Nel pannello dei risultati di axe, filtra per ID di regola label-content-name-mismatch. Ogni elemento segnalato mostrerà il suo nome accessibile calcolato accanto al testo visibile, rendendo immediatamente evidente la discrepanza. Prendi nota del selettore dell'elemento e ispeziona il DOM per identificare la fonte della sovrascrittura del nome accessibile. Lighthouse mostrerà gli stessi errori nella categoria "Accessibility" con un riferimento a WCAG 2.5.3.
  2. \n
  3. Ispezione manuale con gli strumenti di sviluppo del browser: Apri il pannello Accessibilità del browser (Chrome DevTools → Elements → scheda Accessibility, oppure Firefox DevTools → scheda Accessibility). Seleziona ciascun elemento interattivo che ha testo visibile. Controlla nella sezione "Computed Properties" il campo Name dell'elemento. Confronta questo valore con l'etichetta visibile. Se il nome calcolato non contiene il testo dell'etichetta visibile come sottostringa, l'elemento non soddisfa il criterio 2.5.3.
  4. \n
  5. Test con screen reader usando NVDA + Firefox: Apri Firefox con NVDA in esecuzione. Naviga tra i vari elementi interattivi usando il tasto Tab. Ascolta ciò che NVDA annuncia come nome dell'elemento. Prendi nota di eventuali discrepanze tra il nome annunciato e il testo visualizzato sullo schermo. Usa l'Elenco elementi di NVDA (Insert+F7) per scorrere tutti i link e i pulsanti e confrontare in blocco i nomi annunciati con le etichette visive.
  6. \n
  7. Test con screen reader usando JAWS + Chrome: Apri Chrome con JAWS in esecuzione. Passa in rassegna tutti i controlli interattivi con il tasto Tab. JAWS annuncerà il nome accessibile seguito dal ruolo. Quando il nome annunciato non include il testo visibile, registra l'elemento. Inoltre, usa la "Browse Mode" di JAWS e il visualizzatore virtuale per vedere il nome accessibile calcolato per ciascun controllo.
  8. \n
  9. Test con screen reader usando VoiceOver + Safari (macOS/iOS): Attiva VoiceOver (Command+F5 su macOS). Usa Tab o VO+Freccia destra per navigare tra gli elementi interattivi. VoiceOver annuncia il nome accessibile per ciascun controllo. Su iOS, scorri verso destra con un dito per spostarti tra gli elementi e ascoltare eventuali discrepanze tra nome e etichetta.
  10. \n
  11. Test di riconoscimento vocale con Voice Control (macOS/iOS) o Dragon: Attiva Voice Control su macOS (Impostazioni di sistema → Accessibilità → Voice Control). Dì "Show names" per visualizzare le etichette di tutti gli elementi interattivi. Verifica che le etichette mostrate da Voice Control corrispondano al testo visibile sullo schermo. Prova ad attivare i controlli pronunciando il testo dell'etichetta visibile — qualsiasi controllo che non risponde al suo nome visibile rappresenta un errore rispetto al criterio 2.5.3. Ripeti con Dragon NaturallySpeaking su Windows, se disponibile, usando il comando "Click [label]".
  12. \n
\n\n

Come correggere

\n\n

Pulsante con aria-label che sovrascrive il testo — Non corretto

\n
<!-- FAIL: aria-label sostituisce completamente il testo visibile \"Search\"\n     con \"Execute query\", compromettendo l'input vocale -->\n<button aria-label='Execute query'>\n  Search\n</button>
\n\n

Pulsante con aria-label che sovrascrive il testo — Corretto

\n
<!-- PASS: Rimuovere completamente l'aria-label non corrispondente.\n     Il testo visibile del pulsante \"Search\" diventa automaticamente il suo nome accessibile.\n     Gli utenti che usano la voce possono dire \"Click Search\" per attivarlo. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (alternativa): Se è necessario un contesto aggiuntivo,\n     assicurarsi che il nome accessibile CONTENGA il testo visibile. -->\n<button aria-label='Search products'>\n  Search\n</button>
\n\n

Link con aria-labelledby che punta a testo non correlato — Non corretto

\n
<!-- FAIL: aria-labelledby fa riferimento a un'intestazione \"Our Services\"\n     ma il link visivamente riporta \"Learn more\",\n     quindi il nome accessibile è \"Our Services\" invece di \"Learn more\" -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>
\n\n

Link con aria-labelledby che punta a testo non correlato — Corretto

\n
<!-- PASS: Usare aria-labelledby per concatenare il testo del link con l'intestazione.\n     Il nome accessibile diventa \"Learn more Our Services\",\n     che contiene l'etichetta visibile \"Learn more\". -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (alternativa): Rendere il testo visibile del link autoesplicativo\n     in modo che non sia necessaria alcuna sovrascrittura. -->\n<a href='/services'>Learn more about our services</a>
\n\n

Pulsante con icona in cui aria-label è in conflitto con il testo visibile — Non corretto

\n
<!-- FAIL: Il pulsante mostra un'icona del carrello E il testo \"Cart\".\n     L'aria-label 'View shopping basket' non contiene \"Cart\",\n     quindi gli utenti vocali che dicono \"Click Cart\" non ottengono risposta. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>
\n\n

Pulsante con icona in cui aria-label è in conflitto con il testo visibile — Corretto

\n
<!-- PASS: L'aria-label contiene il testo visibile \"Cart\" come sottostringa.\n     Gli utenti vocali possono dire \"Click Cart\" o \"Click View Cart\" e in entrambi i casi funziona. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (preferito): Rimuovere aria-label e nascondere l'icona dall'albero.\n     Il contenuto testuale del pulsante \"Cart\" diventa direttamente il nome accessibile. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>
\n\n

Campo di input con etichetta visibile ma aria-label non corrispondente — Non corretto

\n\n

(Content truncated due to token limit — please retry this article.)