WCAG 3.2.4: Identificazione coerente

Cosa significa questa regola

Il Criterio di Successo WCAG 3.2.4 — Identificazione coerente — stabilisce che i componenti che hanno la stessa funzionalità all’interno di un insieme di pagine web devono essere identificati in modo coerente. Ciò significa che ogni volta che un elemento interattivo o un’immagine svolge la stessa funzione, deve avere lo stesso nome o etichetta accessibile ogni volta che appare nel sito.

Il termine "identificati" in questo contesto si riferisce al modo in cui un componente è presentato alle tecnologie assistive e agli utenti. Questo include il testo dell’etichetta visibile, l’attributo aria-label o aria-labelledby, il testo alt su un’immagine, l’attributo title o il nome accessibile calcolato dall’albero di accessibilità del browser. Se un pulsante di ricerca appare su ogni pagina di un sito, deve essere sempre chiamato "Search" — non "Search" sulla homepage, "Find" sulla pagina di elenco prodotti e "Go" sulla pagina di checkout.

Questo criterio si applica a un insieme di pagine web, che le WCAG definiscono come una raccolta di pagine che condividono uno scopo comune e sono prodotte dallo stesso autore. Questo copre un intero sito web, un’applicazione web o un modulo multi-step che si estende su diversi URL. I componenti che sono solo visivamente simili ma svolgono funzioni diverse non sono tenuti a condividere lo stesso nome — il requisito è specificamente legato alla funzionalità identica.

Cosa è considerato conforme: Un’icona di navigazione che apre un menu hamburger è etichettata in modo coerente come "Open navigation menu" (o equivalente) su tutte le pagine. Un’icona del carrello ha sempre il testo alt o il nome accessibile "Shopping cart". Un pulsante di logout è sempre etichettato "Log out". Una variazione nella formulazione per la stessa funzione costituisce una non conformità.

Cosa è considerato non conforme: Un pulsante di invio etichettato "Submit" nel modulo di registrazione ma etichettato "Send" nel modulo di contatto quando entrambi i pulsanti svolgono lo stesso scopo funzionale di trasmettere i dati inseriti dall’utente. Un pulsante icona con una lente di ingrandimento etichettato "Search" sulla maggior parte delle pagine ma "Ara" su una singola sottopagina tradotta senza una strategia linguistica coerente.

Eccezione ufficiale: Le WCAG specificano esplicitamente che è accettabile avere due componenti con lo stesso nome accessibile se svolgono funzioni diverse — in tal caso, la funzione diversa li distingue. Il criterio si applica solo quando la funzione è identica ma la denominazione è incoerente.

Perché è importante

L’identificazione incoerente crea un onere sproporzionato per gli utenti che si affidano a strategie di navigazione non visive o basate su schemi. I gruppi più gravemente colpiti includono gli utenti di screen reader, le persone con disabilità cognitive e gli utenti con disabilità motorie che si affidano a software di controllo vocale.

Gli utenti di screen reader costruiscono un modello mentale di un sito web ascoltando i nomi degli elementi mentre si spostano con il tasto Tab o navigano per landmark. Quando un pulsante che svolgeva la stessa funzione nella pagina precedente ha ora un nome diverso, l’utente deve fermarsi, indagare e ri-orientarsi — un’esperienza che richiede tempo ed è frustrante. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva. Anche solo una frazione di questa popolazione che interagisce con un sito etichettato in modo incoerente incontrerà barriere significative.

Gli utenti con disabilità cognitive, incluse le persone con dislessia, disturbi dell’attenzione o deficit di memoria, dipendono fortemente da una denominazione prevedibile per ridurre il carico cognitivo. Incontrare un’icona o un controllo familiare con un nome diverso costringe a reimparare e genera ansia. Un’etichettatura coerente riduce lo sforzo necessario per costruire una memoria procedurale quando si usa regolarmente un sito.

Gli utenti di controllo vocale (che usano strumenti come Dragon NaturallySpeaking o Voice Control di Apple) pronunciano il nome di un controllo per attivarlo. Se il nome accessibile di un pulsante differisce da ciò che si aspettano in base all’esperienza precedente con il sito, il loro comando vocale fallirà silenziosamente — il software semplicemente non troverà una corrispondenza. Questo rende l’interfaccia di fatto inutilizzabile in quel momento.

Uno scenario concreto reale: Consideriamo una piattaforma di e-commerce turca che vende abbigliamento. Nella pagina della griglia dei prodotti, ogni articolo ha un pulsante con un’icona a forma di cuore il cui nome accessibile è "Add to favourites". Nella pagina di dettaglio del prodotto, il nome accessibile dello stesso cuore è "Kaydet" (turco per "Save"). Un utente di screen reader che ha imparato ad attivare il pulsante a forma di cuore per nome nella pagina a griglia ora non riesce a trovare il controllo equivalente nella pagina di dettaglio senza un’esplorazione esaustiva. Potrebbe abbandonare completamente il sito.

Oltre all’accessibilità, un’etichettatura coerente favorisce la SEO. I motori di ricerca analizzano i nomi accessibili e il testo dei link per comprendere il contenuto della pagina. Un’etichettatura incoerente per link funzionalmente identici (ad esempio, "Read more", "Continue reading", "Learn more" che puntano tutti alle pagine di dettaglio degli articoli) diluisce i segnali di parole chiave e rende più difficile per i crawler comprendere la struttura del sito.

Regole Axe-core correlate

WCAG 3.2.4 richiede test manuali perché gli strumenti automatici non possono determinare l’intento semantico tra pagine diverse o sapere che due componenti con nomi diversi svolgono la stessa funzione. Nessuna regola di axe-core mappa direttamente a questo criterio. Ecco perché l’automazione non è sufficiente e cosa devono fare invece i tester:

• Test manuale richiesto — coerenza tra pagine: Axe-core valuta una singola pagina in isolamento. Non ha alcun meccanismo per confrontare il nome accessibile di un pulsante "Search" sulla homepage con un pulsante "Find" su una pagina di prodotto, perché non mantiene un inventario dei nomi dei componenti tra pagine diverse. Un tester umano deve catalogare gli elementi funzionali ripetuti e verificare che la loro denominazione sia uniforme su tutte le pagine in cui compaiono.
• Test manuale richiesto — coerenza del testo alt di icone e immagini: Gli strumenti automatici possono rilevare il testo alt mancante (tramite la regola image-alt) ma non possono determinare se due immagini che svolgono lo stesso scopo hanno lo stesso testo alt su pagine diverse. Ad esempio, un’icona della stampante su una pagina delle ricevute e la stessa icona della stampante su una pagina di fattura possono avere entrambe un testo alt — ma se una riporta "Print" e l’altra "Print this page", un essere umano deve giudicare se ciò costituisce un’incoerenza ai sensi del 3.2.4.
• Test manuale richiesto — coerenza delle etichette ARIA: Axe-core verifica che le etichette ARIA siano presenti e non vuote, ma non controlla se i valori di aria-label per lo stesso tipo di componente siano coerenti sull’intero insieme di pagine. Un tester deve ispezionare l’albero di accessibilità su più pagine e confrontare i nomi dei controlli funzionalmente identici.
• Test manuale richiesto — etichette dei controlli di modulo: Le regole automatiche come label verificano che gli input siano associati a etichette, ma non controllano se un campo "Username" nella pagina di login è etichettato "Username" anche nella pagina di recupero account (anziché "Email" o "User ID") quando entrambi i campi accettano lo stesso tipo di input e svolgono lo stesso ruolo funzionale.

Come testare

1. Pre-scansione automatizzata: Esegui axe DevTools o Lighthouse su ogni pagina per far emergere eventuali violazioni correlate, come nomi accessibili mancanti (image-alt, button-name, link-name). Risolvi prima queste — non puoi valutare la coerenza dei nomi se i nomi sono assenti. Prendi nota dei nomi accessibili riportati per i componenti ripetuti nei risultati della scansione.
2. Crea un inventario dei componenti: Elenca manualmente tutti i componenti funzionali che si ripetono tra le pagine — menu di navigazione, campi di ricerca, pulsanti di invio, pulsanti icona, link breadcrumb, link ai social media, pulsanti di stampa/condivisione e controlli di paginazione. Registra il nome accessibile di ogni istanza usando il pannello Accessibility del browser (Chrome DevTools > Elements > Accessibility, o Firefox Accessibility Inspector).
3. Confronta i nomi tra le pagine: Per ogni tipo di componente nel tuo inventario, verifica che ogni istanza abbia lo stesso nome accessibile. Evidenzia qualsiasi discrepanza. Presta particolare attenzione ai componenti che compaiono nelle intestazioni, nei footer e nelle sidebar delle pagine, poiché sono quelli che più probabilmente vengono etichettati in modo incoerente tra i vari template.
4. Test con screen reader usando NVDA + Firefox: Vai alla homepage, quindi usa l’elenco degli elementi di NVDA (Insert + F7) per aprire l’elenco dei pulsanti e dei link. Prendi nota dei nomi dei controlli ripetuti. Poi vai su tre o quattro altre pagine rappresentative e ripeti. Ascolta eventuali variazioni di nome su controlli funzionalmente identici.
5. Test con screen reader usando VoiceOver + Safari (macOS/iOS): Usa il Rotor (VO + U) per aprire l’elenco dei pulsanti o dei link su ogni pagina. Confronta i nomi degli elementi ripetuti. Su iOS, scorri tra gli elementi interattivi su pagine equivalenti e annota eventuali differenze di denominazione.
6. Test con screen reader usando JAWS + Chrome: Usa il cursore virtuale di JAWS e l’elenco dei campi modulo (Insert + F5) e dei link (Insert + F7) su più pagine. Conferma che i controlli identici condividano nomi identici in tutto il sito.
7. Test di controllo vocale: Usando Windows Voice Access o Dragon NaturallySpeaking, pronuncia il nome di un controllo ripetuto su una pagina (ad esempio, "Click Search"). Vai su un’altra pagina e pronuncia lo stesso comando. Se non funziona, i nomi sono incoerenti dal punto di vista funzionale.

Come correggere

Pulsante di ricerca con etichette incoerenti — Errato

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Pulsante di ricerca con etichette incoerenti — Corretto

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Immagine icona usata per la stessa azione con testo alt diverso — Errato

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Immagine icona usata per la stessa azione con testo alt diverso — Corretto

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Pulsante di chiusura della navigazione con nome incoerente — Errato

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Pulsante di chiusura della navigazione con nome incoerente — Corretto

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Link di condivisione social con nomi variabili — Errato

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Link di condivisione social con nomi variabili — Corretto

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Errori comuni

• Usare valori di aria-label diversi in template diversi per lo stesso componente: Quando sviluppatori diversi costruiscono i template di pagina in modo indipendente senza una libreria di componenti condivisa, i pulsanti icona come chiudi, cerca e carrello ricevono spesso etichette ad hoc. Definisci un design system token o un componente condiviso per ogni elemento interattivo ripetuto in modo che il nome accessibile sia definito una sola volta e riutilizzato ovunque.
• Tradurre i nomi accessibili in modo incoerente tra pagine multilingue: Un sito può etichettare correttamente un pulsante di ricerca come "Search" in inglese ma poi usare un equivalente turco incoerente — a volte "Ara", a volte "Arama Yap" — a seconda di quale template di pagina è stato localizzato per primo. Mantieni una singola chiave di traduzione per l’etichetta di ogni componente e applicala in tutti i file di localizzazione.
• Aggiungere suffissi specifici del contesto a controlli altrimenti identici: Etichettare i pulsanti "Add to cart — Blue T-Shirt", "Add to cart — Red Dress" ecc. quando la funzione principale (aggiungere al carrello) è la stessa non è automaticamente una violazione del 3.2.4 — le WCAG consentono la disambiguazione — ma farlo in modo incoerente (a volte con suffisso, a volte senza) crea confusione. Scegli un modello e applicalo in modo uniforme.
• Affidarsi al testo visibile dell’etichetta per garantire la coerenza mentre gli override di aria-label differiscono: Quando un pulsante mostra visivamente "Search" ma un template aggiunge aria-label='Search the site' e un altro non ha aria-label (quindi il nome accessibile è derivato solo dal testo visibile), gli screen reader annunceranno nomi diversi anche se il pulsante appare uguale. Verifica l’intero calcolo del nome accessibile, non solo l’etichetta visibile.
• Consentire agli editor del CMS di cambiare liberamente il testo dei pulsanti senza governance sull’accessibilità: I sistemi di gestione dei contenuti che espongono le etichette dei pulsanti come campi modificabili permettono agli editor di rinominare "Submit" in "Send" o "Gönder" in base alle preferenze personali. Limita la possibilità di modificare le etichette per i componenti funzionali dell’interfaccia utente o aggiungi una validazione che avvisi gli editor quando un’etichetta proposta si discosta dallo standard stabilito.
• Non controllare widget di terze parti o componenti incorporati: I widget di chat, i banner per il consenso ai cookie e gli iframe di pagamento inseriti da terze parti spesso contengono pulsanti etichettati in modo diverso rispetto alle convenzioni del sito ospitante. Esamina e, ove possibile, configura i nomi accessibili di terze parti affinché siano allineati alle tue convenzioni di denominazione, oppure documenta la deviazione come eccezione nota.
• Usare il testo del tooltip (attributo title) come unico nome accessibile in alcune istanze ma aria-label in altre: L’attributo title non è annunciato in modo affidabile da tutte le tecnologie assistive ed è considerato una fonte debole per il nome accessibile. Se alcune istanze di un componente ripetuto usano title e altre usano aria-label, i nomi calcolati possono differire a causa delle differenze di gestione tra browser e screen reader.
• Dare per scontato che i controlli di paginazione siano esenti perché i loro numeri differiscono: I controlli "Next page" e "Previous page", anche quando includono un numero di pagina nella loro etichetta (ad esempio, "Go to page 3"), devono applicare un modello coerente. Mescolare "Next" su alcune pagine con "Next page" o "İleri" su altre per lo stesso controllo di paginazione viola il 3.2.4.
• Non testare i componenti di header e footer su ogni template di pagina distinto: I siti hanno spesso più template di pagina (homepage, pagina di categoria, pagina articolo, checkout). I componenti di header e footer possono essere resi in modo leggermente diverso tra i template. I tester che controllano solo uno o due template possono non rilevare incoerenze introdotte da override specifici del template.
• Confondere il 3.2.4 con il 3.2.3 (Navigazione coerente): I team a volte credono che se l’ordine di navigazione è coerente (3.2.3), lo siano anche i nomi — ma si tratta di requisiti separati. Una barra di navigazione nella stessa posizione su ogni pagina (conformità al 3.2.3) può comunque violare il 3.2.4 se i suoi link sono etichettati in modo diverso tra le pagine. Affronta esplicitamente entrambi i criteri nel tuo processo di QA.

Relazione con le normative sull’accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti di accessibilità vincolanti per un’ampia gamma di servizi digitali pubblici e privati. La Circolare impone la conformità a standard di accessibilità riconosciuti a livello internazionale — in pratica allineandosi alle WCAG 2.2 Livello AA — e collega tale conformità al Logo di Accessibilità (Erişilebilirlik Logosu) rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.2.4 Identificazione coerente è un criterio di Livello AA, il che significa che è un requisito obbligatorio — non una raccomandazione facoltativa — per le organizzazioni che desiderano ottenere o mantenere l’Erişilebilirlik Logosu. La mancata implementazione di un’identificazione coerente in un servizio digitale impedirà la piena conformità al livello AA e, di conseguenza, l’idoneità al logo.

La Circolare copre esplicitamente i seguenti tipi di entità, tutte tenute ad affrontare il WCAG 3.2.4 nelle loro interfacce web e mobile: istituzioni pubbliche e agenzie governative; banche e fornitori di servizi finanziari; ospedali e piattaforme sanitarie; operatori di telecomunicazioni con 200,000 o più abbonati; piattaforme di e-commerce; agenzie di viaggio e servizi di prenotazione; aziende di trasporto privato; e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (Milli Eğitim Bakanlığı).

Per queste organizzazioni, l’implicazione pratica è significativa. I grandi siti istituzionali — come il portale di internet banking di una banca, il sistema di prenotazione appuntamenti di un ospedale o il sistema informativo studenti di un’università — in genere comprendono centinaia di pagine e sono costruiti da più team di sviluppo nel corso di molti anni. L’etichettatura incoerente dei controlli ripetuti (pulsanti di azione sull’account, barre di ricerca, icone di navigazione) su queste pagine è una modalità di errore comune e facilmente trascurata. I programmi di conformità devono includere audit di coerenza tra pagine come fase di test dedicata, non solo scansioni automatiche su singole pagine.

Le organizzazioni turche che perseguono l’Erişilebilirlik Logosu dovrebbero integrare i controlli WCAG 3.2.4 nella governance del loro design system, nei flussi di lavoro di gestione dei contenuti e nelle pipeline di QA. In particolare, ogni componente UI riutilizzabile dovrebbe avere il proprio nome accessibile definito come costante non modificabile a livello di design system, con chiavi di traduzione gestite centralmente per garantire che il turco e qualsiasi altra variante linguistica rimangano coerenti su tutte le pagine e i template in cui il componente appare.