WCAG 3.2.3: Navigazione coerente

Cosa Significa Questa Regola

Il Criterio di Successo WCAG 3.2.3 — Navigazione coerente (Livello AA) stabilisce che i componenti di navigazione ripetuti su più pagine di un sito web devono comparire ogni volta nello stesso ordine relativo, a meno che non sia l’utente stesso ad aver provocato un cambiamento di tale ordine. Il criterio si applica a qualsiasi insieme di pagine web che condividono uno scopo comune o che fanno parte dello stesso sito o applicazione.

L’espressione "stesso ordine relativo" è importante: le WCAG non richiedono che la navigazione contenga sempre lo stesso numero di elementi, né che non possano comparire altri elementi tra le voci di navigazione. Ciò che richiedono è che la sequenza dei link di navigazione, così come appare a un utente che si muove nell’interfaccia, rimanga coerente da una pagina all’altra. Per esempio, se nella navigazione principale della homepage compaiono nell’ordine “Home”, “Products”, “About” e “Contact”, gli stessi elementi devono comparire nella stessa sequenza in ogni altra pagina in cui esiste quel blocco di navigazione.

Il criterio copre tutti i meccanismi di navigazione ripetuti: menu di navigazione principale del sito, breadcrumb, gruppi di link nel footer, menu laterali, link per saltare la navigazione, barre di ricerca e qualsiasi altro componente interattivo che aiuti l’utente a muoversi all’interno del sito. Si applica indipendentemente dal fatto che tali componenti siano implementati come landmark <nav>, liste di link <ul>, menu personalizzati arricchiti con ARIA o qualsiasi altro pattern di markup.

Cosa è considerato conforme: I blocchi di navigazione compaiono nello stesso ordine relativo in ogni pagina in cui sono ripetuti. Gli elementi possono essere aggiunti, evidenziati o marcati come attivi (ad esempio, il link alla pagina corrente è visivamente distinto), purché la sequenza complessiva non cambi. Anche un riordino avviato dall’utente — come in una dashboard personalizzabile in cui l’utente trascina i pannelli in nuove posizioni — è conforme, perché il cambiamento ha origine dall’utente.

Cosa è considerato non conforme: Una navigazione principale che elenca “Home → Products → Contact → About” nella homepage ma “Home → About → Products → Contact” in una pagina di dettaglio prodotto non rispetta il criterio 3.2.3. Allo stesso modo, un sito che inserisce condizionalmente link aggiuntivi in posizioni arbitrarie nella navigazione in base a logiche interne (senza azione dell’utente) non sarebbe conforme.

Eccezione ufficiale: La specifica dichiara esplicitamente che il requisito non si applica quando è l’utente ad aver avviato il cambiamento dell’ordine. Questa è l’unica eccezione normativa. I cambiamenti guidati dal sistema, dalla logica del server o da algoritmi di personalizzazione — non direttamente attivati dall’utente — non rientrano in questa eccezione.

Perché È Importante

La navigazione coerente è fondamentale per l’accessibilità cognitiva. Gli utenti che si affidano alla memoria spaziale e a schemi prevedibili per orientarsi — incluse persone con disabilità cognitive, disturbi dell’attenzione, lesioni cerebrali traumatiche o declino cognitivo legato all’età — dipendono fortemente dall’assunto che la navigazione di un sito si trovi nello stesso posto e nello stesso ordine ogni volta che la incontrano. Quando la navigazione cambia in modo inatteso, questi utenti devono reimparare il layout a ogni pagina, aumentando drasticamente il carico cognitivo e la probabilità di errori o abbandono.

Per gli utenti ciechi o ipovedenti che navigano con screen reader (NVDA, JAWS, VoiceOver), una navigazione coerente riduce il tempo speso a cercare landmark noti. Un utente di screen reader che ha memorizzato che il link “Contact” è il quarto elemento nella navigazione principale può premere il tasto Tab quattro volte in qualsiasi pagina per raggiungerlo — ma solo se l’ordine è garantito come stabile. Un ordine incoerente distrugge questa efficienza e costringe l’utente ad ascoltare l’intera navigazione a ogni caricamento di pagina.

Per gli utenti con disabilità motorie che si affidano alla sola tastiera, a sistemi di accesso a interruttore o al tracciamento oculare, ogni pressione di tasto o movimento della testa ha un costo reale. Una navigazione prevedibile riduce il numero di interazioni necessarie per raggiungere le destinazioni visitate più frequentemente. Secondo l’Organizzazione Mondiale della Sanità, oltre 1,3 miliardi di persone nel mondo vivono con qualche forma di disabilità, molte delle quali si affidano a tecnologie assistive che traggono beneficio diretto da interfacce coerenti e prevedibili.

Per gli utenti con disturbi della lettura come la dislessia, scansionare una barra di navigazione richiede già uno sforzo. Un posizionamento e un ordine coerenti consentono di fare affidamento su ancore visive — posizione, forma, colore — invece di dover rileggere le etichette ogni volta.

Uno scenario concreto reale: immagina un paziente che utilizza il sito web di un ospedale per prenotare visite di controllo. La navigazione nella homepage elenca “Services”, “Appointments”, “Doctors” e “Contact” in quest’ordine. Il paziente passa al profilo di un medico e cerca “Appointments” in seconda posizione — ma in quella pagina la navigazione è stata riorganizzata per iniziare con “Doctors” seguito da “Appointments”. Il paziente, già stressato, deve ripassare l’intero menu. Per un utente con disabilità cognitiva o con alfabetizzazione limitata, questo attrito può fare la differenza tra completare l’attività e rinunciare del tutto.

Oltre all’accessibilità, la navigazione coerente ha misurabili benefici per la SEO e l’usabilità. I crawler dei motori di ricerca attraversano i link di navigazione per scoprire e indicizzare i contenuti; una struttura di link stabile migliora l’efficienza di scansione e la distribuzione dell’equità dei link interni. I test di usabilità mostrano costantemente che una navigazione prevedibile riduce i tempi di completamento dei compiti e i tassi di errore per tutti gli utenti, non solo per quelli con disabilità.

Regole Axe-core Correlate

WCAG 3.2.3 richiede test manuali. Non esiste una regola automatizzata di axe-core che possa segnalare un ordine di navigazione incoerente, perché gli strumenti automatici non dispongono del contesto tra pagine necessario per confrontare le sequenze di navigazione. Uno scanner automatico valuta una singola pagina isolatamente e non può osservare se la navigazione su quella pagina differisce dalla navigazione su altre venti pagine dello stesso sito.

• Confronto manuale tra pagine (nessun ID di regola axe): I tester devono visitare più pagine all’interno dello stesso sito e registrare manualmente l’ordine degli elementi di navigazione su ciascuna pagina, quindi confrontare tali registrazioni. Gli strumenti automatici non possono eseguire questo controllo perché dovrebbero analizzare più pagine simultaneamente, mantenere lo stato tra i caricamenti di pagina e applicare un giudizio semantico su quali elementi costituiscano lo stesso componente di navigazione — tutte attività che richiedono ragionamento contestuale umano.
• Perché l’automazione non è sufficiente: Anche gli strumenti euristici che segnalano problemi legati alla navigazione in genere verificano la presenza di landmark di navigazione (come la regola axe landmark-one-main o region), non la coerenza dell’ordine tra pagine. Il confronto dell’ordine richiede una metodologia di audit a livello di sito, non una scansione di singola pagina. Per questo motivo il criterio 3.2.3 è classificato come richiedente revisione manuale in tutti i principali framework di test di accessibilità, inclusi axe-core, Lighthouse e IBM Equal Access Checker.

Come Eseguire i Test

1. Esegui una scansione automatizzata per un contesto di base: Usa axe DevTools, Lighthouse o un’estensione del browser su pagine rappresentative per confermare che gli elementi di navigazione siano correttamente marcati come landmark <nav> o con role='navigation'. Sebbene questi strumenti non segnalino incoerenze nell’ordine, ti aiutano a identificare ciò che viene trattato come navigazione tra le pagine. Documenta eventuali problemi con la struttura dei landmark prima di procedere ai controlli manuali.
2. Seleziona un campione rappresentativo di pagine: Scegli almeno da cinque a dieci pagine da diverse sezioni del sito — homepage, una pagina di categoria, una pagina di dettaglio prodotto o articolo, una pagina con form e la pagina dei contatti. Se il sito ha migliaia di pagine, utilizza un campione stratificato che copra tutti i principali template. Registra l’URL e il tipo di pagina per ciascuna.
3. Mappa manualmente l’ordine di navigazione: Su ogni pagina del campione, apri l’albero di accessibilità del browser (Chrome DevTools → pannello Accessibility, oppure Firefox Accessibility Inspector) ed elenca tutti i link all’interno della navigazione principale nell’ordine in cui compaiono nel DOM. Annota anche l’ordine con cui compaiono visivamente. Se il CSS sta riordinando visivamente gli elementi (ad esempio usando flex-direction: row-reverse o le proprietà order), l’ordine visivo può differire dall’ordine nel DOM — entrambi devono essere coerenti.
4. Confronta tra le pagine: Metti affiancate le tue liste dell’ordine di navigazione. Evidenzia qualsiasi pagina in cui la sequenza degli elementi di navigazione condivisi differisce dal riferimento stabilito sulla homepage. Annota quali elementi si sono spostati e in quale direzione.
5. Test di navigazione da tastiera (NVDA + Firefox): Apri NVDA, avvia Firefox e vai alla homepage. Premi D per passare al successivo landmark e individua la navigazione principale. Usa il tasto Tab per muoverti tra i link di navigazione e pronuncia ad alta voce o annota l’ordine. Poi passa a una seconda pagina (ad esempio una pagina interna di articolo) e ripeti. Ascolta eventuali cambiamenti nella sequenza di annuncio dei link.
6. Test con screen reader (VoiceOver + Safari su macOS): Attiva VoiceOver (Command + F5), apri Safari e usa il Web Rotor (Control + Option + U) per aprire il menu Links o Landmarks. Vai alla navigazione principale e annota l’ordine degli elementi. Ripeti su almeno tre diversi tipi di pagina e confronta.
7. Test JAWS + Chrome: Apri JAWS, avvia Chrome e premi R per scorrere le regioni finché non raggiungi la navigazione principale. Usa Tab per scorrere i link e registra l’ordine. Ripeti sui vari tipi di pagina.
8. Verifica le eccezioni avviate dall’utente: Se il sito offre funzionalità di personalizzazione o di configurazione della navigazione, verifica che qualsiasi riordino avvenga solo dopo un’azione esplicita dell’utente (ad esempio, l’utente fa clic su “Customize Menu” e trascina gli elementi). Conferma che lo stato riordinato venga poi mantenuto in modo coerente — il nuovo ordine deve a sua volta rimanere coerente su tutte le pagine dopo che l’utente lo ha impostato.

Come Correggere

Rendering lato server incoerente — Non corretto

<!-- Homepage navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<!-- Product detail page navigation — order changed by CMS template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/products'>Products</a></li>
  </ul>
</nav>

Rendering lato server incoerente — Corretto

<!-- Shared navigation partial (e.g., _nav.html or a component) used on every page -->
<!-- The active page is indicated with aria-current, not by reordering -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/' aria-current='page'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- On the Products page, only aria-current moves — the order stays identical -->

Riordino visivo tramite CSS che crea incoerenza — Non corretto

<!-- DOM order: Home, Products, About, Contact -->
<!-- CSS on interior pages uses flex order to visually move Contact first -->
<style>
  /* Applied only on interior page templates */
  nav ul li:last-child { order: -1; }
</style>
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Visual order becomes Contact, Home, Products, About — inconsistent with homepage -->

Riordino visivo tramite CSS che crea incoerenza — Corretto

<!-- Use consistent DOM order and consistent CSS across all templates -->
<!-- Do not use CSS 'order' property to rearrange navigation items differently per template -->
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Same DOM order and same CSS flex order on every page template -->

Navigazione dinamica riordinata da algoritmo — Non corretto

<!-- JavaScript reorders nav links based on most-visited analytics without user action -->
<script>
  // Anti-pattern: fetches user behaviour data and reorders nav items automatically
  fetch('/api/user-nav-preferences').then(r => r.json()).then(order => {
    const nav = document.querySelector('nav ul');
    order.forEach(id => nav.appendChild(document.getElementById(id)));
  });
</script>
<nav aria-label='Main navigation'>
  <ul>
    <li id='nav-home'><a href='/'>Home</a></li>
    <li id='nav-products'><a href='/products'>Products</a></li>
    <li id='nav-about'><a href='/about'>About</a></li>
    <li id='nav-contact'><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Navigazione dinamica riordinata da algoritmo — Corretto

<!-- If personalisation is desired, require an explicit user action and keep order stable otherwise -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Personalisation button lets user reorder — change only applies after they interact -->
<button type='button' aria-controls='main-nav-list' id='customize-nav'>Customize Navigation Order</button>
<!-- The user-chosen order is then persisted consistently across all pages -->

Errori Comuni

• Utilizzare diversi template di CMS che definiscono ciascuno la navigazione in modo indipendente, permettendo che nel tempo si insinuino differenze sottili nell’ordine man mano che i template vengono aggiornati separatamente invece che da un singolo componente o partial condiviso.
• Promuovere elementi di navigazione “in evidenza” o “stagionali” a posizioni diverse in base a campagne di marketing senza assicurarsi che il resto dell’ordine di navigazione rimanga invariato — per esempio, spostare temporaneamente “Sale” alla seconda posizione su alcune pagine e alla quinta su altre.
• Usare le proprietà CSS order, flex-direction: row-reverse o il posizionamento CSS Grid per riordinare visivamente gli elementi di navigazione in modo diverso tra i template di pagina, creando una discrepanza tra l’ordine visivo (che gli utenti vedenti percepiscono) e l’ordine nel DOM (che gli utenti da tastiera e con screen reader seguono).
• Inserire elementi di navigazione sensibili al contesto in posizioni arbitrarie — per esempio, aggiungere un link “Back to Category” come secondo elemento nelle pagine prodotto ma non nelle altre pagine, spostando tutti gli elementi successivi di una posizione e rompendo la sequenza attesa.
• Consentire a piattaforme di A/B testing o di analytics di riordinare i link di navigazione come parte delle varianti di esperimento, senza considerare che il riordino si applica in modo incoerente tra pagine e sessioni.
• Considerare il breadcrumb trail come esente da questo criterio quando in realtà è un meccanismo di navigazione ripetuto — breadcrumb che compaiono in posizioni diverse rispetto ad altri elementi di pagina tra i vari template violano anch’essi il criterio 3.2.3.
• Riordinare la navigazione nel footer in modo diverso rispetto alla navigazione principale quando i link nel footer duplicano la navigazione principale — se entrambi compaiono in ogni pagina, entrambi devono mantenere un ordine coerente in modo indipendente e in relazione l’uno con l’altro.
• Applicare miglioramenti di navigazione guidati da JavaScript che riordinano gli elementi in base alla posizione di scroll, alle dimensioni della viewport o ai dati di sessione senza iniziativa dell’utente — per esempio, un mega-menu che fa emergere dinamicamente categorie di primo livello diverse a seconda della sezione del sito in cui si trova l’utente.
• Non verificare la coerenza della navigazione dopo un redesign del sito o una migrazione di CMS, dando per scontato che gli sviluppatori riprodurranno naturalmente l’ordine originale quando in realtà i diversi tipi di pagina vengono ricostruiti da team diversi partendo da zero.
• Confondere “navigazione coerente” con “stessa navigazione su ogni pagina” — i team a volte concludono erroneamente che aggiungere o rimuovere elementi di navigazione per determinati ruoli utente (ad esempio utenti autenticati vs. ospiti) violi il criterio 3.2.3. Non è così, purché l’ordine relativo degli elementi condivisi rimanga invariato.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale n. 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale (n. 32933) il 21 giugno 2025, stabilisce obblighi vincolanti in materia di accessibilità per un’ampia gamma di soggetti pubblici e privati che gestiscono servizi digitali in Turchia. La Circolare impone la conformità a standard di accessibilità riconosciuti a livello internazionale — con le WCAG 2.2 Livello AA come principale riferimento tecnico — e collega la conformità all’Erişilebilirlik Logosu (Accessibility Logo), un marchio di certificazione rilasciato dal Ministero della Famiglia e dei Servizi Sociali ai soggetti che raggiungono la soglia di accessibilità richiesta.

WCAG 3.2.3 Navigazione coerente è un criterio di Livello AA, il che significa che è un requisito obbligatorio per i soggetti che intendono ottenere l’Erişilebilirlik Logosu. Le organizzazioni che non forniscono una navigazione coerente nei propri servizi digitali non raggiungeranno il profilo di conformità AA completo richiesto per la certificazione, indipendentemente dalle loro prestazioni sugli altri criteri.

I seguenti tipi di soggetti rientrano nell’ambito di applicazione della Circolare Presidenziale 2025/10 e devono quindi considerare la conformità al criterio 3.2.3 come un obbligo legale e non come una semplice raccomandazione di best practice:

• Istituzioni pubbliche e agenzie governative a tutti i livelli, incluse i ministeri, i comuni e gli enti collegati allo Stato, i cui siti web e portali digitali devono essere navigabili in modo coerente in tutte le sezioni.
• Piattaforme di e-commerce che operano in Turchia, dove la coerenza della navigazione è particolarmente critica dato che gli utenti si muovono tra homepage, pagine di categoria, pagine prodotto, carrello e pagine di checkout — che in genere condividono tutte la stessa barra di navigazione.
• Banche e istituzioni finanziarie regolamentate dal diritto bancario turco, i cui portali di online banking e siti informativi devono fornire una navigazione prevedibile per servire tutti i clienti, incluse le persone con disabilità cognitive o motorie.
• Ospedali e fornitori di servizi sanitari, dove i pazienti — spesso in situazioni di stress — si affidano a una navigazione coerente per trovare la prenotazione delle visite, i risultati degli esami e le informazioni di contatto per le emergenze senza attrito cognitivo.
• Società di telecomunicazioni con 200.000 o più abbonati, i cui portali clienti, siti di supporto e interfacce di gestione dell’account devono mantenere una navigazione coerente su migliaia di pagine e template rivolti agli utenti.
• Agenzie di viaggio e società di trasporto privato, dove i flussi di prenotazione in più fasi che coprono ricerca, selezione, dati dei passeggeri e pagamenti devono presentare la navigazione in un ordine coerente lungo tutto il percorso.
• Scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE), i cui siti web servono studenti, genitori e personale — incluse persone con disturbi dell’apprendimento che si affidano fortemente a una navigazione prevedibile per accedere alle risorse educative.

Per le organizzazioni in Turchia che sviluppano o verificano servizi digitali, il criterio 3.2.3 dovrebbe essere integrato nel processo di assicurazione qualità già nella fase di progettazione dei template e dei componenti. L’uso di un componente di navigazione condiviso, renderizzato da un’unica fonte di verità — che si tratti di un include lato server, di un componente di un framework front-end o di un elemento globale di un CMS headless — è sia l’approccio tecnico più affidabile sia la posizione di conformità più difendibile ai sensi dei requisiti della Circolare. Gli audit di accessibilità presentati come parte del processo di richiesta dell’Erişilebilirlik Logosu dovrebbero includere la verifica dell’ordine di navigazione tra pagine come passaggio di test documentato.