WCAG 4.1.2: Nome, Ruolo, Valore

WCAG 4.1.2 richiede che tutti i componenti dell’interfaccia utente abbiano un nome e un ruolo determinabili a livello di programmazione e che stati, proprietà e valori possano essere sia letti sia impostati dalle tecnologie assistive. Questo garantisce che gli screen reader e altri strumenti possano identificare, descrivere e interagire correttamente con ogni elemento della pagina.

Cosa Significa Questa Regola

WCAG 4.1.2 — Name, Role, Value è un criterio di successo di Livello A sotto il principio Robust. Richiede che per ogni componente dell’interfaccia utente — inclusi elementi di form, pulsanti, link, widget personalizzati, frame e controlli interattivi — le seguenti tre condizioni siano soddisfatte:

Name (Nome): Ogni componente deve avere un nome accessibile che le tecnologie assistive possano leggere ad alta voce o mostrare tramite un display braille. Il nome può derivare dal contenuto dell’elemento (ad esempio, il testo all’interno di un <button>), da un elemento label, da un attributo aria-label, da un riferimento aria-labelledby o da un attributo title.
Role (Ruolo): Ogni componente deve avere un ruolo che comunichi il suo scopo alle tecnologie assistive. Gli elementi HTML nativi hanno ruoli impliciti (un <button> ha il ruolo button, un <input type='checkbox'> ha il ruolo checkbox). I widget personalizzati costruiti a partire da elementi generici come <div> o <span> devono dichiarare esplicitamente un ruolo usando l’attributo ARIA role.
Value (Valore: Stati e Proprietà): Qualsiasi stato o valore corrente significativo per l’utente — se una checkbox è selezionata, se un widget di disclosure è espanso, se un campo è obbligatorio — deve essere esposto in modo programmabile affinché le tecnologie assistive possano riportarlo e gli utenti possano modificarlo, ove applicabile.

Un componente rispetta questo criterio quando il suo nome accessibile non è vuoto, il suo ruolo è valido e semanticamente appropriato e tutti gli stati rilevanti (come aria-checked, aria-expanded o aria-required) sono applicati correttamente e mantenuti sincronizzati con l’interfaccia visiva. Un componente non rispetta il criterio quando uno qualsiasi di questi tre elementi è assente, errato o non sincronizzato — per esempio, un pulsante toggle personalizzato che cambia colore visivamente ma non aggiorna mai il suo stato aria-pressed.

L’eccezione ufficiale delle WCAG riguarda i componenti che sono intenzionalmente non esposti alle API di accessibilità — per esempio, elementi puramente decorativi o contenuti nascosti con aria-hidden='true'. Tuttavia, nascondere contenuti attivi o focalizzabili con aria-hidden (per esempio applicandolo all’elemento <body>) costituisce di per sé una violazione, perché rimuove tutto il contenuto della pagina dall’albero di accessibilità.

Perché È Importante

Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva. Per le persone cieche o ipovedenti che si affidano a screen reader come JAWS, NVDA o VoiceOver, il nome accessibile e il ruolo di ogni componente interattivo sono il mezzo principale — e spesso l’unico — per capire cosa fa un controllo e come usarlo. Se un pulsante non ha un nome accessibile, l’utente di screen reader sente solo “button” senza alcuna indicazione del suo scopo. Se un menu a discesa personalizzato non ha un ruolo, l’utente non può distinguerlo dal testo statico.

Le persone con disabilità motorie che usano il software tramite accesso a interruttore, strumenti di controllo vocale come Dragon NaturallySpeaking o navigazione da tastiera dipendono anch’esse da questo criterio. Il software di controllo vocale associa i comandi pronunciati (“click Submit”) ai nomi accessibili. Se il nome accessibile di un pulsante non corrisponde alla sua etichetta visibile, i comandi vocali falliscono completamente.

L’accessibilità cognitiva è altrettanto rilevante. Etichette coerenti e prevedibili riducono il carico cognitivo per le persone con dislessia, deficit di memoria o disturbi dell’attenzione. Quando i cambiamenti di stato — come l’apertura di una modale o il fatto che un campo di form diventi obbligatorio — non vengono annunciati dalle tecnologie assistive, gli utenti possono disorientarsi e non riuscire a completare i compiti.

Consideriamo uno scenario concreto reale: una piattaforma di e-commerce turca mostra un pulsante “Add to Cart” costruito come un <div> con un gestore di click e un’icona del carrello. Visivamente sembra un pulsante. Ma poiché manca di role='button', di un nome accessibile e di tabindex='0', un utente di screen reader che naviga con la tastiera non incontra nulla — l’elemento è completamente invisibile alla sua tecnologia assistiva. Non può aggiungere prodotti al carrello, venendo di fatto escluso dall’intera esperienza di acquisto.

Oltre all’accessibilità, componenti correttamente nominati e strutturati migliorano la SEO perché i crawler dei motori di ricerca si basano sul markup semantico per comprendere la struttura della pagina e l’intento interattivo. Migliorano anche la testabilità, poiché i framework di test automatizzati possono individuare e interagire in modo più affidabile con elementi che hanno ruoli ed etichette significativi.

Regole Axe-core Correlate

Le seguenti regole axe-core sono direttamente associate a WCAG 4.1.2. Ognuna prende di mira una specifica categoria di errori relativi a name, role o value:

aria-allowed-attr: Verifica che gli attributi ARIA applicati a un elemento siano consentiti per il ruolo di quell’elemento. Per esempio, applicare aria-checked a un elemento con role='link' è non valido e viene segnalato, perché il ruolo link non supporta aria-checked.
aria-command-name: Garantisce che gli elementi con ruoli ARIA di comando (link, button, menuitem) abbiano un nome accessibile non vuoto. Un pulsante composto solo da un’icona, senza testo di etichetta e senza aria-label, verrebbe segnalato qui.
aria-hidden-body: Segnala il caso specifico in cui aria-hidden='true' è stato applicato all’elemento <body>, il che rimuove l’intera pagina dall’albero di accessibilità e rende tutto il contenuto invisibile agli screen reader.
aria-input-field-name: Verifica che gli elementi con ruoli ARIA di input (textbox, searchbox, spinbutton, slider, combobox) abbiano un nome accessibile. Un campo di ricerca personalizzato costruito con role='textbox' ma senza etichetta verrebbe segnalato.
aria-meter-name: Verifica che gli elementi con role='meter' abbiano un nome accessibile, così che gli utenti di screen reader capiscano quale quantità il misuratore sta rappresentando (per esempio, utilizzo dello spazio di archiviazione o livello della batteria).
aria-progressbar-name: Garantisce che gli elementi con role='progressbar' abbiano un nome accessibile, così che gli utenti sappiano quale processo o operazione è in corso invece di sentire solo “progress bar”.
aria-required-attr: Verifica che gli elementi che usano un determinato ruolo ARIA includano tutti gli attributi richiesti dalla specifica ARIA per quel ruolo. Per esempio, role='slider' richiede aria-valuenow, aria-valuemin e aria-valuemax; l’omissione di uno qualsiasi di questi viene segnalata.
aria-roles: Valida che tutti i valori assegnati all’attributo role siano ruoli ARIA validi e non astratti. Errori di battitura, ruoli inventati o ruoli astratti (come role='widget') usati direttamente sugli elementi vengono tutti segnalati.
aria-tooltip-name: Verifica che gli elementi con role='tooltip' abbiano un nome accessibile. Un elemento tooltip vuoto non fornisce alcun valore agli utenti di screen reader e rappresenta un errore di etichettatura.
button-name: Verifica che gli elementi <button> e gli elementi con role='button' abbiano un nome accessibile non vuoto. Questo intercetta i pulsanti a icona senza aria-label e i pulsanti vuoti usati come trigger decorativi.
frame-title: Richiede che gli elementi <iframe> e <frame> abbiano un attributo title non vuoto che descriva il contenuto del frame. Senza di esso, gli utenti di screen reader non possono determinare lo scopo del contenuto incorporato e potrebbero non sapere se entrare o saltare il frame.
input-button-name: Verifica che gli elementi <input> di tipo submit, reset, button e image abbiano un nome accessibile — tramite un attributo value o, per gli input di tipo immagine, un attributo alt.

È importante notare che, sebbene gli strumenti automatici rilevino molti errori relativi a name, role e value, alcune violazioni richiedono test manuali. Gli scanner automatici non possono verificare se un nome accessibile è significativo — un pulsante etichettato “click here” tecnicamente supera il controllo automatico per la presenza di un nome, ma non comunica il suo vero scopo. Allo stesso modo, il fatto che i cambiamenti di stato (come il toggle di aria-expanded quando si apre un menu) vengano annunciati correttamente durante l’interazione in tempo reale può essere confermato solo tramite test pratici con screen reader.

Come Testare

Scansione automatizzata con axe DevTools o Lighthouse: Installa l’estensione browser axe DevTools (Chrome o Firefox) oppure esegui un audit Lighthouse in Chrome DevTools nella scheda Accessibility. Attiva la scansione dell’intera pagina e filtra i risultati per il tag WCAG 4.1.2. Cerca in particolare violazioni di button-name, frame-title, aria-required-attr, aria-roles e aria-input-field-name. Ogni risultato includerà l’elemento in violazione, una descrizione dell’errore e una correzione suggerita. Esporta i risultati e dai priorità prima agli elementi con gravità Critical e Serious.
Test di navigazione da tastiera: Disconnetti il mouse e naviga l’intera pagina usando il tasto Tab. Verifica che ogni elemento focalizzabile riceva il focus visibile, che l’indicatore di focus nativo del browser (o uno personalizzato) sia chiaramente visibile e che tu possa attivare tutti i controlli usando Invio o Barra spaziatrice. Qualsiasi elemento che raggiungi e che non puoi identificare dal solo contesto — senza guardare lo schermo — indica probabilmente un errore nel nome accessibile.
Test con screen reader usando NVDA e Firefox: Apri NVDA (Windows, gratuito), avvia Firefox e naviga la pagina usando Tab per spostarti tra gli elementi interattivi e la lista degli elementi di NVDA (Insert+F7) per sfogliare tutti i pulsanti, i link e i campi di form. Per ogni elemento interattivo, ascolta cosa annuncia NVDA. Dovrebbe leggere il nome dell’elemento, il ruolo e qualsiasi stato rilevante (ad esempio, “Subscribe, button” o “Email address, required, edit text”). Segnala qualsiasi elemento annunciato senza nome o con un ruolo errato.
Test con screen reader usando VoiceOver e Safari (macOS/iOS): Abilita VoiceOver (Command+F5 su macOS), apri Safari e usa VO+Freccia destra per navigare tra gli elementi. Usa il Rotor di VoiceOver (VO+U) per elencare tutti i controlli di form e i pulsanti. Verifica che i nomi siano descrittivi, i ruoli appropriati e che gli stati vengano aggiornati dinamicamente quando interagisci (per esempio, il toggle di un accordion personalizzato dovrebbe far annunciare a VoiceOver “expanded” o “collapsed”).
Test con screen reader usando JAWS e Chrome: Avvia JAWS e apri Chrome. Usa il tasto Tab per navigare tra gli elementi interattivi e il cursore virtuale di JAWS (Insert+F3 per un elenco dei campi di form) per rivedere le etichette. Presta particolare attenzione ai widget personalizzati costruiti con ARIA — verifica che i cambiamenti di stato attivati dall’interazione da tastiera siano riflessi in tempo reale in ciò che JAWS annuncia.
Verifica dello stato dei widget personalizzati: Per qualsiasi widget personalizzato (accordion, pannello a schede, combobox, modale), interagisci completamente usando solo la tastiera. A ogni passo, verifica che lo screen reader annunci il corretto aggiornamento di stato — per esempio, l’apertura di un widget di disclosure dovrebbe far annunciare “expanded” e la chiusura “collapsed”. Se lo stato visivo cambia ma lo screen reader rimane silenzioso, significa che aria-expanded è assente o non viene aggiornato in modo programmabile.

Come Correggere

Pulsante Solo Icona Senza Nome Accessibile — Errato

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Pulsante Solo Icona Senza Nome Accessibile — Corretto

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Widget Toggle Personalizzato Senza Ruolo o Stato — Errato

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Widget Toggle Personalizzato Senza Ruolo o Stato — Corretto

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

iframe Senza Etichetta — Errato

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

iframe Senza Etichetta — Corretto

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Barra di Avanzamento Personalizzata Senza Attributi ARIA Richiesti — Errato

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Barra di Avanzamento Personalizzata Senza Attributi ARIA Richiesti — Corretto

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Errori Comuni

Usare role='button' su un <div> senza aggiungere tabindex='0' — l’elemento viene annunciato come pulsante dagli screen reader ma rimane irraggiungibile tramite la navigazione con Tab, rendendolo inutilizzabile per chi usa solo la tastiera.
Applicare aria-label a un elemento non interattivo — aggiungere aria-label a un <div> o a uno <span> senza ruolo non ha alcun effetto; l’etichetta viene ignorata dalla maggior parte dei browser perché l’elemento non ha un ruolo a cui il nome possa riferirsi.
Lasciare aria-expanded statico dopo aver implementato un widget di disclosure — impostare aria-expanded='false' in HTML e non aggiornarlo mai con JavaScript significa che l’attributo è sempre errato dopo il primo click, annunciando lo stato opposto agli utenti di screen reader.
Usare aria-hidden='true' su un contenitore che contiene elementi focalizzabili — questo nasconde il contenitore dall’albero di accessibilità ma non dal focus da tastiera, così gli utenti di screen reader possono raggiungere con Tab elementi che non possono sentire, causando estrema confusione.
Fornire un placeholder come unica etichetta per un <input> — il testo del placeholder scompare alla digitazione, non è annunciato in modo affidabile come etichetta da tutti gli screen reader e non soddisfa il requisito di nome accessibile per i campi di form.
Usare un ruolo ARIA non valido o astratto come role='widget' o role='structure' — questi sono ruoli di base nella specifica ARIA e non sono destinati all’uso diretto; non forniscono informazioni semantiche significative e possono essere ignorati o causare errori nelle tecnologie assistive.
Fare riferimento a un ID di elemento inesistente in aria-labelledby — se l’ID indicato da aria-labelledby non esiste nel DOM, il calcolo del nome accessibile fallisce e l’elemento rimane senza nome.
Usare value invece di aria-label per <input type='image'> — i pulsanti di tipo immagine richiedono un attributo alt per il loro nome accessibile; l’attributo value viene ignorato per il calcolo del nome sugli input di tipo immagine.
Omettere l’attributo title sugli elementi <iframe> che caricano contenuti di terze parti — gli sviluppatori spesso presumono che gli embed noti (mappe, widget di pagamento, video player) si descrivano da soli, ma gli utenti di screen reader devono essere informati dello scopo del frame prima di decidere se entrarvi.
Dimenticare di aggiornare dinamicamente i nomi accessibili quando il contenuto cambia — se l’etichetta di un pulsante cambia visivamente da “Play” a “Pause” ma l’aria-label rimane “Play”, agli utenti di screen reader viene fornita un’informazione errata sullo stato e sull’azione corrente.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità digitale allineati a WCAG 2.2. WCAG 4.1.2 — Name, Role, Value è un criterio di Livello A, il che significa che si colloca al livello più fondamentale di conformità. In base alla circolare, la conformità di Livello A non è facoltativa — è la base che tutte le entità interessate devono raggiungere.

La circolare si applica a un’ampia gamma di tipologie di entità che operano in Turchia. Le istituzioni pubbliche — incluse i ministeri, i comuni e le agenzie statali — devono raggiungere la conformità entro un anno dalla data di pubblicazione della circolare. Le entità del settore privato — incluse piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari privati, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE) — devono raggiungere la conformità entro due anni.

WCAG 4.1.2 è particolarmente rilevante per le organizzazioni turche perché molti siti web turchi moderni si basano su componenti interattivi personalizzati — caroselli di prodotti, FAQ a fisarmonica, flussi di checkout passo-passo e dashboard bancari — che sono spesso implementati senza ruoli ARIA, nomi o gestione degli stati adeguati. Un pulsante di checkout personalizzato senza nome accessibile, o uno slider di calcolo del prestito privo di aria-valuenow, non rappresenta semplicemente una scarsa esperienza utente: in base alla circolare, costituisce una violazione della conformità legale.

Per le banche e le piattaforme di e-commerce soggette alla circolare, le violazioni di WCAG 4.1.2 nei flussi critici di transazione — moduli di pagamento, modali di autenticazione, dashboard di account — sono particolarmente rischiose. Un combobox personalizzato, stilizzato visivamente, per selezionare una filiale bancaria che manca del markup ARIA corretto può impedire a un utente di screen reader di completare del tutto una transazione, esponendo l’istituzione sia ad azioni regolatorie sia a reclami per discriminazione.

Le organizzazioni che utilizzano l’SDK di overlay Accsible possono beneficiare del rilevamento automatico e della correzione a runtime di molte violazioni relative a Name, Role, Value — inclusa l’iniezione di nomi accessibili mancanti, la correzione di ruoli ARIA non validi su pattern di widget noti e la sincronizzazione degli attributi di stato sui componenti interattivi. Tuttavia, le organizzazioni dovrebbero considerare il supporto automatico dell’overlay come un complemento, non un sostituto, di uno sviluppo HTML semantico corretto, in particolare per i widget personalizzati complessi in cui la gestione programmabile dello stato deve essere integrata nella logica dell’applicazione fin dall’inizio.