WCAG 2.4.8: Posizione

Cosa Significa Questa Regola

WCAG 2.4.8 Location è un criterio di livello AAA sotto il principio Operable. Stabilisce: «Information about the user's location within a set of Web pages is available.» In termini pratici, questo significa che il tuo sito web deve fornire segnali chiari e persistenti che indichino agli utenti esattamente dove si trovano all'interno della struttura complessiva del sito in qualsiasi momento.

Questo criterio si applica ogni volta che un sito web è composto da più pagine organizzate in una gerarchia o sequenza significativa — ad esempio, un sito di e-commerce con categorie, sottocategorie e pagine di prodotto, o un portale governativo con dipartimenti e sotto-sezioni. Se un utente arriva su una pagina, dovrebbe essere in grado di rispondere alla domanda «Dove mi trovo in questo sito?» senza dover indovinare o fare affidamento esclusivamente sulla memoria.

Tecniche accettabili per soddisfare questo criterio includono, ma non si limitano a:

• Breadcrumb trail — un ausilio di navigazione che mostra il percorso dalla home page del sito alla pagina corrente (ad es. Home > Products > Laptops > 15-inch Models).
• Site map — una pagina o un pannello dedicato che mostra la struttura complessiva del sito e evidenzia o contrassegna la posizione corrente.
• Link di navigazione evidenziati o visivamente distinti — menu di navigazione che indicano chiaramente la sezione o la pagina attiva, spesso integrati con un attributo aria-current per gli utenti di tecnologie assistive.
• Passaggi numerati in un processo multi-step — indicatori come «Step 2 of 5» in una procedura di checkout o in un wizard di compilazione che comunicano la posizione sequenziale.

Una pagina supera questo criterio se è disponibile almeno un meccanismo affidabile che informi l'utente della sua posizione corrente all'interno della struttura del sito. Una pagina non supera il criterio se non esiste alcun meccanismo di questo tipo — ad esempio, se la barra di navigazione non ha alcuna indicazione visiva o programmatica della pagina corrente, non c'è alcun breadcrumb e non viene mostrato alcun indicatore di step.

È importante notare che WCAG 2.4.8 non impone una tecnica specifica; richiede che sia presente qualche indicatore di posizione efficace. Tuttavia, affinché l'indicatore sia realmente accessibile, deve essere anche percepibile dalle tecnologie assistive come gli screen reader, non solo visivamente evidente agli utenti vedenti. Ciò significa che indicatori puramente visivi (come un link in grassetto senza alcuna modifica all'etichetta accessibile) possono essere insufficienti da soli se non sono esposti in modo programmatico.

Non ci sono eccezioni ufficiali previste da WCAG per questo criterio oltre alla comprensione generale che si applica a insiemi di pagine correlate. Una singola pagina web autonoma che non fa parte di un insieme più ampio non avrebbe bisogno di soddisfare questo criterio, poiché non esiste alcuna «posizione all'interno di un insieme» da comunicare.

Perché È Importante

Sapere dove ci si trova all'interno di un ambiente digitale è un bisogno di orientamento di base che la maggior parte degli utenti dà per scontato — finché i segnali non sono presenti. WCAG 2.4.8 affronta una barriera reale e diffusa sperimentata da diversi gruppi distinti di utenti.

Gli utenti con disabilità cognitive sono tra quelli più significativamente interessati. Condizioni come il disturbo da deficit di attenzione, i deficit di memoria e i traumi cranici acquisiti possono rendere difficile tenere traccia del proprio percorso attraverso un sito complesso. Senza un breadcrumb o un segnale simile, un utente può disorientarsi, non essere sicuro di come tornare a una categoria padre o non riuscire a capire come la pagina corrente si relazioni ai contenuti che ha già visto. Secondo l'Organizzazione Mondiale della Sanità, oltre un miliardo di persone nel mondo vive con qualche forma di disabilità, e i deficit cognitivi rappresentano una parte significativa e spesso poco servita di quella popolazione.

Gli utenti di screen reader — che sono tipicamente ciechi o ipovedenti — fanno grande affidamento sulla struttura programmatica per comprendere il contesto della pagina. Un utente vedente può dare un'occhiata a un link di navigazione evidenziato o a un elemento del breadcrumb in grassetto per orientarsi istantaneamente. Un utente di screen reader, al contrario, deve interpretare la pagina attraverso un output audio sequenziale. Senza un attributo aria-current="page" sul link di navigazione attivo o un breadcrumb correttamente strutturato con etichette accessibili, non riceve un segnale di orientamento equivalente e può dover navigare a lungo solo per determinare dove si trova.

Gli utenti con disabilità motorie che navigano tramite tastiera, accesso a switch o dispositivi di eye-tracking traggono beneficio dagli indicatori di posizione perché riducono la necessità di una navigazione ridondante e faticosa. Se un utente sa già di trovarsi nella sezione «Support» di un sito aziendale, non ha bisogno di ri-esaminare l'intera struttura di navigazione ogni volta che carica una nuova pagina.

Considera uno scenario concreto: una persona con demenza in fase iniziale sta navigando nel portale online di una banca turca per trovare informazioni sui tassi dei mutui. Clicca su diverse pagine e non è più sicura se si trovi ancora nella sezione di banking personale o se sia finita nell'area di banking per le imprese. Senza un breadcrumb o un elemento di navigazione evidenziato che indichi chiaramente la sezione corrente, potrebbe chiudere il browser per frustrazione o commettere un errore costoso — come fare domanda per il prodotto sbagliato. Un semplice breadcrumb ben implementato (ad es. Ana Sayfa > Bireysel Bankacılık > Krediler > Konut Kredisi) risolverebbe immediatamente questa confusione.

Oltre all'accessibilità, gli indicatori di posizione forniscono benefici misurabili in termini di usabilità e SEO. I dati strutturati dei breadcrumb (utilizzando Schema.org BreadcrumbList) possono comparire direttamente nei risultati di ricerca di Google come rich snippet, migliorando i tassi di click-through. Una struttura del sito chiara riduce anche i tassi di rimbalzo, poiché gli utenti che comprendono dove si trovano hanno maggiori probabilità di esplorare contenuti correlati piuttosto che abbandonare il sito.

Regole Axe-core Correlate

WCAG 2.4.8 richiede test manuali perché gli strumenti automatici non possono determinare in modo affidabile se un meccanismo di localizzazione è presente, significativo e accessibile in tutti i contesti. Nessuna regola axe-core mappa direttamente a questo criterio. Ecco perché l'automazione non è sufficiente e cosa deve coprire la valutazione manuale:

• Presenza di un meccanismo di localizzazione (manuale) — Uno scanner automatico può rilevare se esiste un elemento breadcrumb nel DOM, ma non può determinare se quel breadcrumb riflette accuratamente la reale architettura informativa del sito, se è presente su ogni pagina all'interno di un insieme o se è il tipo corretto di indicatore di posizione per il modello di navigazione del sito. Uno strumento potrebbe trovare un elemento <nav aria-label="breadcrumb"> e non segnalare problemi, anche se il breadcrumb appare solo su alcune pagine o contiene informazioni gerarchiche errate.
• Accuratezza e completezza (manuale) — Gli strumenti automatici non possono verificare che le informazioni sulla posizione siano accurate. Un breadcrumb che mostra sempre «Home > Current Page» indipendentemente dalla gerarchia reale supererebbe una scansione automatica ma non soddisferebbe questo criterio, perché non rappresenta in modo veritiero la posizione dell'utente all'interno dell'insieme di pagine.
• Esposizione programmatica (parzialmente automatizzata) — Sebbene axe-core possa segnalare la mancanza di attributi aria-current sui link di navigazione in alcune configurazioni, non può determinare in modo conclusivo se l'assenza di aria-current costituisca una violazione del 2.4.8 senza comprendere la struttura complessiva del sito e il ruolo di ciascun elemento di navigazione.
• Coerenza all'interno dell'insieme di pagine (manuale) — Un meccanismo di localizzazione deve essere disponibile in tutto l'insieme rilevante di pagine, non solo su alcune. Le scansioni automatiche in genere valutano una pagina alla volta e non possono verificare se un meccanismo è presente in modo coerente su un intero sito o sezione.

Come Testare

1. Identifica l'insieme di pagine: Determina se la pagina in esame appartiene a un insieme di pagine correlate con una gerarchia definita (ad es. una struttura di navigazione multilivello, un wizard passo-passo o una libreria di contenuti categorizzata). Se la pagina è un documento autonomo, questo criterio potrebbe non essere applicabile.
2. Esegui una scansione automatica come base: Usa axe DevTools (estensione del browser) o Lighthouse in Chrome DevTools per eseguire un audit di accessibilità. Sebbene nessuno dei due strumenti verifichi direttamente il criterio 2.4.8, controlla problemi correlati come la mancanza di attributi aria-current sui link di navigazione, landmark <nav> senza etichetta e struttura dei breadcrumb mancante. Questi risultati supportano — ma non sostituiscono — la revisione manuale.
3. Ispeziona visivamente la presenza di un meccanismo di localizzazione: Cerca un breadcrumb, un link attivo evidenziato o visivamente distinto nella navigazione, un contatore di step o un link alla site map. Verifica che il meccanismo rifletta accuratamente la posizione della pagina corrente nella gerarchia del sito.
4. Testa con uno screen reader — NVDA + Firefox: Apri NVDA, vai alla pagina e premi D per scorrere i landmark. Trova i landmark di navigazione e ascolta eventuali indicazioni sulla pagina o sezione corrente. Controlla se l'elemento di navigazione attivo viene annunciato in modo diverso (ad es. «current page» o simile, tipicamente tramite aria-current="page"). Esamina il breadcrumb, se presente, e verifica che ogni livello venga annunciato con il proprio testo di link e che la posizione corrente sia chiaramente identificata.
5. Testa con VoiceOver + Safari (macOS/iOS): Attiva VoiceOver (Command + F5), vai al breadcrumb o alla navigazione principale usando VO + U per aprire il Rotor e seleziona «Links» o «Landmarks». Ascolta come viene annunciato l'elemento di navigazione attivo o l'elemento corrente del breadcrumb. Verifica che la posizione corrente sia distinguibile dagli altri elementi di navigazione.
6. Testa con JAWS + Chrome: Usa Insert + F7 per aprire la lista dei link e Insert + F6 per aprire la lista delle intestazioni. Vai al breadcrumb o all'area di navigazione e conferma che la pagina o sezione corrente sia identificabile in modo programmatico. Controlla che aria-current venga letto ad alta voce (JAWS lo annuncia come «current» per l'elemento rilevante).
7. Testa su più pagine dell'insieme: Naviga attraverso almeno tre-cinque pagine all'interno della stessa sezione o gerarchia e conferma che il meccanismo di localizzazione si aggiorni correttamente su ogni pagina e che sia presente in modo coerente in tutto l'insieme.
8. Ispeziona il DOM: Usa i DevTools del browser per verificare che i link del breadcrumb abbiano nomi accessibili descrittivi, che l'elemento corrente utilizzi aria-current="page" (per la pagina corrente) o aria-current="true" (per lo step corrente in un processo) e che il breadcrumb sia racchiuso in un elemento <nav> con un'etichetta accessibile come aria-label="Breadcrumb".

Come Correggere

Navigazione Breadcrumb Mancante — Non Corretto

<!-- No breadcrumb or location indicator present.
     Users have no way to determine their location in the site hierarchy. -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

Navigazione Breadcrumb Mancante — Corretto

<!-- A breadcrumb nav is added above the main content.
     aria-label distinguishes it from main navigation.
     aria-current="page" marks the current location for screen readers.
     The list structure communicates hierarchy. -->
<nav aria-label='Breadcrumb'>
  <ol>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
    <li><a href='/products/laptops/15-inch' aria-current='page'>15-inch Laptops</a></li>
  </ol>
</nav>
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

Link di Navigazione Attivo Senza Indicatore Programmatico — Non Corretto

<!-- The active link is styled differently in CSS, but there is no
     programmatic signal. Screen reader users cannot distinguish it
     from the other navigation links. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Link di Navigazione Attivo Senza Indicatore Programmatico — Corretto

<!-- aria-current="page" is added to the active link.
     Screen readers will announce this link as "current" or "current page"
     depending on the assistive technology, giving users a clear
     programmatic location signal in addition to the visual styling. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active' aria-current='page'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Form Multi-Step Senza Indicatore di Step — Non Corretto

<!-- A multi-step checkout form with no indication of current step.
     Users cannot determine how far they are through the process
     or how many steps remain. -->
<form>
  <h1>Shipping Information</h1>
  <!-- form fields -->
  <button type='submit'>Next</button>
</form>

Form Multi-Step Senza Indicatore di Step — Corretto

<!-- A progress indicator communicates the user's position in the sequence.
     aria-label on the nav provides context.
     aria-current="step" marks the active step for assistive technologies.
     The visible text "Step 2 of 4" is also available for all users. -->
<nav aria-label='Checkout progress'>
  <ol>
    <li><a href='/checkout/cart'>Cart</a></li>
    <li aria-current='step'><strong>Shipping</strong></li>
    <li>Payment</li>
    <li>Confirmation</li>
  </ol>
</nav>
<form>
  <h1>Shipping Information <span>(Step 2 of 4)</span></h1>
  <!-- form fields -->
  <button type='submit'>Next: Payment</button>
</form>

Errori Comuni

• Fornire un breadcrumb solo sulla home page o solo sulle pagine foglia: Il breadcrumb deve essere presente in modo coerente su tutte le pagine dell'insieme. Visualizzarlo solo sulle pagine di dettaglio prodotto ma non sulle pagine di categoria crea lacune nelle informazioni di orientamento.
• Usare un link attivo stilizzato visivamente senza aggiungere aria-current="page": Un link di navigazione attivo in grassetto o sottolineato comunica la posizione visivamente, ma gli utenti di screen reader non ne traggono alcun beneficio a meno che aria-current="page" non sia presente su quell'elemento.
• Racchiudere il breadcrumb in un elemento <div> invece che in un elemento <nav>: Usare un contenitore non semantico significa che il breadcrumb non è esposto come landmark di navigazione, rendendo più difficile per gli utenti di screen reader trovarlo e interpretarlo.
• Omettere aria-label dal <nav> del breadcrumb quando esiste anche un landmark di navigazione principale: Due landmark <nav> senza etichetta sulla stessa pagina creano ambiguità. Gli screen reader possono annunciarli entrambi semplicemente come «navigation», lasciando gli utenti incapaci di distinguerli.
• Usare aria-current="true" su un link di pagina invece di aria-current="page": Il valore page è il valore semanticamente corretto per identificare la pagina corrente in un contesto di navigazione. Usare true è meno descrittivo e può essere annunciato in modo diverso o meno chiaro dalle tecnologie assistive.
• Fare affidamento esclusivamente sul titolo della pagina per indicare la posizione: Un elemento <title> descrittivo (ad es. «Laptops — 15-inch Models | Acme Store») è utile e richiesto da WCAG 2.4.2, ma non soddisfa da solo il criterio 2.4.8, che richiede un meccanismo che comunichi la posizione all'interno della struttura dell'insieme di pagine, non solo il nome della pagina corrente.
• Costruire breadcrumb che riflettono la struttura degli URL anziché la gerarchia di navigazione: Gli URL e le strutture di navigazione non sempre coincidono. I breadcrumb dovrebbero riflettere l'architettura informativa logica che un utente comprenderebbe, non il percorso URL sottostante, che può essere tecnico o opaco.
• Visualizzare il breadcrumb come testo semplice senza link per i livelli antenati: Se viene mostrata solo la pagina corrente o i livelli antenati non sono linkati, il breadcrumb perde la sua utilità sia come indicatore di posizione sia come ausilio alla navigazione. Gli elementi antenati dovrebbero essere linkati per consentire agli utenti di risalire la gerarchia.
• Contrassegnare l'elemento corrente del breadcrumb solo con una modifica visiva del separatore invece che con aria-current: Cambiare il colore o rimuovere la sottolineatura dall'ultimo elemento del breadcrumb non comunica agli screen reader che rappresenta la pagina corrente. È necessario aggiungere esplicitamente aria-current="page".
• Dimenticare di aggiornare l'indicatore di posizione nelle single-page application (SPA) dopo la navigazione lato client: Nelle SPA costruite con framework come React o Vue, le transizioni di pagina avvengono senza un ricaricamento completo del browser. Se il breadcrumb o l'indicatore di navigazione attivo non viene aggiornato in modo programmatico al cambio di route, mostrerà informazioni di posizione obsolete, il che è peggio che non avere alcun indicatore.

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 vincolanti di accessibilità web e mobile per un'ampia gamma di organizzazioni che operano in Turchia. La circolare impone la conformità a standard di accessibilità riconosciuti a livello internazionale — adottando di fatto il framework WCAG — e si applica a un insieme definito di tipologie di entità, tra cui istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio autorizzate, società di trasporto private e scuole private autorizzate dal Ministero dell'Istruzione Nazionale (MoNE).

WCAG 2.4.8 Location è classificato come criterio di livello AAA, il che significa che non rientra tra i criteri legalmente richiesti di base ai sensi della circolare, che fa riferimento alla conformità di livello A e AA come soglia minima. Tuttavia, la distinzione è importante in diversi modi per le organizzazioni soggette alla regolamentazione.

In primo luogo, alcuni servizi specializzati — in particolare quelli rivolti a utenti con significative difficoltà cognitive o di navigazione, come i portali sanitari per pazienti anziani o le piattaforme educative per studenti con disturbi dell'apprendimento — potrebbero essere tenuti a superare la soglia AA per soddisfare realmente lo spirito degli obblighi di accessibilità previsti dalla legge turca e dalla normativa correlata, come la Legge sulle Persone con Disabilità n. 5378. Implementare il criterio 2.4.8 in questi contesti dimostra un impegno sostanziale, piuttosto che meramente procedurale, all'inclusione.

In secondo luogo, le istituzioni pubbliche turche e le entità private regolamentate sono sempre più soggette a meccanismi di audit e reclamo. Dimostrare una conformità di livello AAA — incluso WCAG 2.4.8 — fornisce una documentazione difendibile di implementazione delle best practice e riduce il rischio regolamentare in caso di un reclamo formale in materia di accessibilità.

In terzo luogo, per le piattaforme di e-commerce e in particolare per le banche, indicatori di posizione come i breadcrumb hanno un valore commerciale diretto oltre alla loro funzione di accessibilità. Un processo di richiesta di mutuo online di una banca turca che includa chiari indicatori di step e una navigazione tramite breadcrumb non solo servirà in modo più efficace gli utenti con disabilità cognitive, ma ridurrà anche i tassi di abbandono e favorirà la conversione — allineando l'investimento in accessibilità con risultati di business misurabili.

Le organizzazioni che utilizzano l'SDK di overlay Accsible possono sfruttare le sue funzionalità integrate di miglioramento dei breadcrumb e di iniezione di aria-current per avvicinare i siti esistenti alla conformità con il criterio 2.4.8 senza richiedere un refactoring completo del codebase. Tuttavia, per una conformità completa e robusta — in particolare per le entità coperte dalla Circolare Presidenziale 2025/10 — l'implementazione lato server o in fase di build di markup semantico per i breadcrumb e gli indicatori di navigazione rimane l'approccio raccomandato, poiché le soluzioni di overlay integrano ma non sostituiscono un markup accessibile di base.