WCAG 2.4.5: Molteplici modalità

Cosa Significa Questa Regola

WCAG 2.4.5 — Multiple Ways è un criterio di successo di livello AA sotto il principio Operable. Richiede che qualsiasi pagina web che faccia parte di un insieme più ampio di pagine web sia raggiungibile tramite almeno due meccanismi di navigazione distinti. In altre parole, un utente non dovrebbe mai essere costretto a fare affidamento su un unico percorso per trovare una pagina.

Meccanismi di navigazione comuni che soddisfano questo criterio includono: una funzione di ricerca a livello di sito, una sitemap (sia come pagina autonoma sia come struttura inline), un indice dei contenuti, un menu di navigazione o una barra laterale coerenti, breadcrumb e link tra pagine correlate. Qualsiasi combinazione di due di questi — o altri meccanismi equivalenti — utilizzati insieme soddisfa il requisito.

Il criterio si applica specificamente a insiemi di pagine web. Una pagina web autonoma che non appartiene a un sito o a un’applicazione più ampia è esente. Inoltre, sono esplicitamente esenti le pagine che sono il risultato di, o un passaggio in, un processo — come una pagina di conferma del checkout, una schermata di avvenuto invio di un modulo o una fase di una procedura guidata. Questo perché tali pagine sono intrinsecamente sequenziali e sarebbe inappropriato o dannoso consentire l’accesso diretto ad esse fuori ordine.

Un pass richiede che almeno due meccanismi di navigazione indipendenti siano presenti, funzionanti e accessibili in tutto il sito. Si ha un fail quando esiste un solo meccanismo — per esempio, un sito che fornisce solo un menu di navigazione superiore senza ricerca, senza sitemap e senza altri ausili di navigazione. Si ha inoltre un fail se il meccanismo secondario non è funzionante o è inaccessibile (ad esempio, una casella di ricerca che non restituisce risultati, o una sitemap nascosta alle tecnologie assistive).

È importante notare che questo criterio non impone alcuna combinazione specifica di meccanismi. La flessibilità è intenzionale: utenti diversi hanno strategie fondamentalmente diverse per trovare i contenuti, e lo standard riconosce questa diversità richiedendo ridondanza invece di prescrivere una soluzione particolare.

Perché È Importante

La navigazione è la base di qualsiasi esperienza web, e le barriere alla navigazione colpiscono in modo sproporzionato le persone con disabilità. Quando esiste un solo percorso di navigazione, gli utenti che non possono usare quel percorso sono di fatto esclusi dai contenuti.

Per gli utenti con disabilità motorie — inclusi coloro che usano accesso a sensori, dispositivi di eye-tracking, software di controllo vocale o navigazione solo da tastiera — i menu gerarchici complessi possono essere estenuanti o impossibili da attraversare in modo efficiente. Una ricerca nel sito consente loro di passare direttamente ai contenuti senza dover navigare attraverso più livelli di menu. Al contrario, utenti con alcune disabilità cognitive o della memoria possono trovare i campi di ricerca aperti confusi o difficili da usare in modo efficace; per loro, una sitemap chiaramente strutturata o un albero di categorie navigabile è molto più utile.

Per gli utenti ciechi che si affidano ai lettori di schermo, un menu di navigazione denso può diventare un ostacolo ripetitivo a ogni visita di pagina, anche con i link di salto. Una sitemap o una scorciatoia di ricerca riduce in modo significativo quel carico cognitivo e fisico. Per gli utenti con ipovisione che usano l’ingrandimento dello schermo, i menu di navigazione ampi possono essere visibili solo parzialmente a livelli di zoom elevati, rendendo una ricerca testuale o una sitemap un fallback fondamentale.

Per gli utenti con disabilità cognitive come la dislessia o i disturbi dell’attenzione, la possibilità di cercare usando termini approssimativi o parziali — invece di dover ricordare o riconoscere l’esatta gerarchia del menu — può fare la differenza tra trovare i contenuti in autonomia e rinunciare del tutto.

Uno scenario concreto nel mondo reale: immagina un utente con artrite reumatoide che visita una piattaforma di e-commerce turca usando la sola tastiera. Il mega-menu del sito richiede interazioni precise di hover del mouse per rivelare le sottocategorie, e il comportamento del focus da tastiera è inaffidabile. Se il sito fornisce anche una barra di ricerca e una sitemap, quell’utente può comunque individuare la pagina di prodotto di cui ha bisogno. Senza queste alternative, il sito è di fatto inutilizzabile per lui — e ciò rappresenta un cliente perso e una potenziale responsabilità legale.

Oltre all’accessibilità, molteplici meccanismi di navigazione offrono benefici misurabili in termini di SEO e usabilità. Le sitemap migliorano la crawlability da parte dei bot dei motori di ricerca. La funzionalità di ricerca nel sito aumenta il coinvolgimento degli utenti e riduce i tassi di rimbalzo. I breadcrumb migliorano i tassi di click-through nelle pagine dei risultati dei motori di ricerca quando sono implementati con dati strutturati. Questi benefici significano che soddisfare il criterio 2.4.5 non è solo un esercizio di conformità — è una buona pratica di web design.

Regole Axe-core Correlate

WCAG 2.4.5 richiede test manuali perché nessuno strumento automatico può determinare in modo affidabile se un sito fornisce una varietà di navigazione sufficiente. Gli scanner automatici possono verificare se elementi specifici esistono e sono sintatticamente corretti, ma non possono valutare l’architettura di navigazione a livello di sito o determinare se una data combinazione di meccanismi è realmente adeguata. Le seguenti considerazioni guidano la valutazione manuale:

• Presenza di una ricerca nel sito (verifica manuale): Gli strumenti automatici non possono confermare se un campo di ricerca è funzionante, restituisce risultati significativi o è accessibile in tutto il sito. Un tester deve verificare manualmente che esista un meccanismo di ricerca, che sia raggiungibile tramite tastiera e che produca risultati pertinenti per query rappresentative.
• Presenza di una sitemap o di un meccanismo di navigazione alternativo (verifica manuale): Gli strumenti non possono determinare se esiste una pagina di sitemap, se è collegata da tutte le pagine o se copre in modo completo i contenuti del sito. Un revisore umano deve confermare che almeno un meccanismo aggiuntivo oltre alla navigazione principale sia disponibile e accessibile.
• Coerenza della navigazione (relativo a 2.4.3 e 3.2.3, verifica manuale): Gli strumenti automatici possono segnalare un ordine incoerente dei componenti tra le pagine, ma non possono giudicare se la strategia di navigazione complessiva rimane coerente e sufficiente per gli utenti con disabilità. È necessaria una revisione manuale su più tipi di pagine rappresentative.
• Accessibilità dei meccanismi secondari (verifica manuale): Anche se esiste una sitemap o una ricerca, una scansione automatica potrebbe non rilevare i casi in cui tali meccanismi non sono accessibili da tastiera, hanno etichette per lettori di schermo scadenti o sono nascosti visivamente in modo da influire sull’usabilità. Test manuali con tastiera e lettore di schermo devono confermare che ogni meccanismo funzioni dall’inizio alla fine.

Come Eseguire i Test

1. Scansione automatizzata — stabilire una baseline: Esegui axe DevTools o Lighthouse su pagine rappresentative del sito. Sebbene nessuno dei due strumenti segnali direttamente violazioni del criterio 2.4.5, utilizza l’audit per identificare eventuali componenti di navigazione (menu, campi di ricerca, breadcrumb) con problemi di accessibilità sottostanti come etichette mancanti, ruoli ARIA impropri o problemi di gestione del focus. Correggi prima questi problemi, poiché un meccanismo di navigazione non funzionante non può essere considerato un “percorso” valido ai sensi del criterio 2.4.5.
2. Catalogare i meccanismi di navigazione: Esamina manualmente il sito ed elenca ogni meccanismo distinto che un utente potrebbe usare per raggiungere una determinata pagina: menu di navigazione superiori, link nel footer, ricerca nel sito, pagine di sitemap, breadcrumb, link a contenuti correlati, indici di categoria e così via. Conferma che almeno due di questi meccanismi siano presenti, funzionanti e disponibili su ogni pagina che non faccia parte di un processo sequenziale.
3. Test di navigazione solo da tastiera: Usando solo i tasti Tab, Invio, le frecce e il tasto Esc (nessun mouse), prova a raggiungere una specifica pagina non home tramite due meccanismi diversi. Ad esempio, usa la barra di ricerca per trovare una pagina di prodotto, quindi usa la sitemap o il menu di navigazione per raggiungere la stessa pagina. Conferma che entrambi i percorsi siano completamente utilizzabili senza mouse.
4. Test con lettore di schermo usando NVDA + Firefox: Apri NVDA, avvia Firefox e naviga alla home page. Usa la modalità browse di NVDA (F6 per i landmark, H per le intestazioni) per individuare il landmark di ricerca e qualsiasi link alla sitemap o di navigazione. Conferma che entrambi i meccanismi vengano annunciati correttamente, che i campi modulo abbiano etichette accessibili e che le pagine di risultati o destinazione si carichino e siano leggibili.
5. Test con lettore di schermo usando VoiceOver + Safari (macOS/iOS): Attiva VoiceOver (Cmd+F5) e usa il Rotor (VO+U) per ispezionare i controlli del modulo e i link della pagina. Conferma che il campo di ricerca sia elencato e etichettato e che i link di navigazione che portano a una sitemap o a un indice alternativo siano presenti e funzionanti.
6. Test con lettore di schermo usando JAWS + Chrome: Usa le combinazioni di tasti di navigazione di JAWS (F per passare ai moduli, Insert+F7 per l’elenco dei link) per verificare che il campo di ricerca e qualsiasi link alla sitemap siano individuabili e utilizzabili sia dalla tastiera sia dal cursore virtuale.
7. Verifica dell’esenzione per i processi sequenziali: Identifica eventuali pagine che rappresentano passaggi di un processo (checkout, moduli multi-step, flussi di login). Conferma che queste pagine non debbano soddisfare il requisito dei percorsi multipli. Documentalo nel tuo audit di accessibilità per evitare falsi fail.
8. Verifica funzionale dei risultati di ricerca: Esegui diverse ricerche rappresentative (nomi di prodotti, titoli di articoli, argomenti di supporto). Conferma che i risultati compaiano, siano pertinenti e che la pagina dei risultati sia accessibile e navigabile tramite tastiera e lettore di schermo.

Come Correggere

Ricerca nel sito mancante — Non corretto

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Ricerca nel sito mancante — Corretto

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Sitemap inaccessibile — Non corretto

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Sitemap inaccessibile — Corretto

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Modulo di ricerca senza etichetta accessibile — Non corretto

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Modulo di ricerca senza etichetta accessibile — Corretto

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Errori Comuni

• Considerare una sitemap XML come meccanismo di navigazione rivolto agli utenti: Una sitemap XML inviata ai motori di ricerca (ad esempio, /sitemap.xml) è un file leggibile dalle macchine e non può essere utilizzato dai visitatori comuni. Solo una pagina di sitemap HTML, navigabile dagli esseri umani, conta come valido secondo meccanismo di navigazione.
• Fornire un modulo di ricerca puramente decorativo o non funzionante: Un campo di ricerca che restituisce sempre risultati vuoti, genera errori all’invio o reindirizza a una pagina 404 non soddisfa il criterio 2.4.5. Il meccanismo deve essere realmente funzionante perché il criterio sia superato.
• Nascondere il link alla sitemap dietro JavaScript che non funziona o è disabilitato: Se l’unico link a una sitemap si trova all’interno di una modale iniettata dinamicamente o di un menu a discesa dipendente da JavaScript che non funziona in determinati ambienti, gli utenti che non possono eseguire quel JavaScript (incluse alcune configurazioni di tecnologie assistive) perdono l’accesso a quel meccanismo di navigazione.
• Applicare display:none o visibility:hidden a un meccanismo di navigazione sui viewport mobili: Nascondere completamente una barra di ricerca o un link alla sitemap nel layout mobile rimuove del tutto quel meccanismo per gli utenti mobili, il che è un fail — anche se il layout desktop è conforme. Collocare il meccanismo dietro un pulsante di attivazione accessibile è accettabile; rimuoverlo dal DOM o dall’albero di accessibilità non lo è.
• Considerare i breadcrumb come secondo meccanismo autonomo senza ulteriore supporto: I breadcrumb mostrano solo il percorso verso la pagina corrente e non sono sufficienti, da soli, ad aiutare un utente a scoprire e navigare verso pagine arbitrarie di un sito. Possono integrare altri meccanismi ma in genere non possono fungere da uno dei due meccanismi richiesti da soli.
• Esentare in modo errato alcune pagine dal requisito: L’esenzione per i processi sequenziali si applica solo alle pagine che sono letteralmente passaggi all’interno di un processo (ad esempio, passaggio 2 di 4 in un checkout). Le pagine di categoria, le pagine di dettaglio prodotto e i post di blog non sono esenti, anche se l’utente vi è arrivato tramite un funnel.
• Usare un campo di ricerca con type='text' invece di type='search' e omettere role='search' nel modulo: Pur non essendo una violazione diretta del criterio 2.4.5, ciò significa che gli utenti di lettori di schermo che navigano per landmark non possono trovare l’area di ricerca. Il meccanismo esiste tecnicamente ma è praticamente più difficile da individuare, minando l’intento del criterio.
• Fornire due meccanismi che sono di fatto identici: Un menu di navigazione superiore e un menu di navigazione nel footer che contengono esattamente gli stessi link nella stessa struttura non costituiscono due meccanismi di navigazione significativamente diversi. L’intento è che utenti con esigenze diverse possano trovare strategie alternative — non che la stessa strategia compaia due volte nella pagina.
• Escludere determinati tipi di pagina dal sistema di navigazione: Alcune configurazioni di CMS collocano i post di blog, le pagine legali o le pagine dell’account utente al di fuori della mappa del sito principale o dell’indice di ricerca. Se gli utenti non possono trovare queste pagine tramite almeno due meccanismi, tali pagine non soddisfano il criterio 2.4.5 indipendentemente da quanto sia ben strutturato il resto del sito.
• Non testare i meccanismi con tecnologie assistive: Poiché il criterio 2.4.5 richiede test manuali, i team che si affidano esclusivamente a strumenti automatici non rileveranno i fail causati da trappole da tastiera nei moduli di ricerca, campi senza etichetta o sitemap presenti nel DOM ma irraggiungibili tramite la navigazione per landmark del lettore di schermo.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale della Turchia n. 2025/10, pubblicata nella Gazzetta Ufficiale (Resmî Gazete) n. 32933 il 21 giugno 2025, stabilisce obblighi vincolanti in materia di accessibilità web per un’ampia gamma di soggetti del settore pubblico e privato. La Circolare impone la conformità a standard di accessibilità riconosciuti a livello internazionale, allineando i requisiti legali turchi a WCAG 2.1 e WCAG 2.2 livello AA come aspettativa di base.

WCAG 2.4.5 — Multiple Ways è un criterio di livello AA, il che significa che rientra pienamente nel livello di conformità richiesto dalla Circolare. I soggetti sottoposti alla regolamentazione devono garantire che tutte le pagine web appartenenti a un insieme forniscano almeno due meccanismi di navigazione, come descritto in questo criterio. Il mancato rispetto di questo requisito costituisce una non conformità diretta al mandato normativo.

I soggetti coperti dalla Circolare Presidenziale 2025/10 includono: istituzioni pubbliche e organi di governo a tutti i livelli; banche e istituzioni finanziarie; ospedali e fornitori di servizi sanitari; piattaforme di commercio elettronico; operatori di telecomunicazioni con 200,000 o più abbonati; agenzie di viaggio; società di trasporto private; e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (Millî Eğitim Bakanlığı, MEB). Ciascuna di queste tipologie di soggetti è tenuta a mantenere una navigazione accessibile e con percorsi multipli sulle proprie proprietà web.

Oltre ai requisiti di conformità obbligatori, il Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı) rilascia l’Erişilebilirlik Logosu (Logo di Accessibilità) alle organizzazioni che dimostrano solide pratiche di accessibilità. Ottenere questo logo richiede la piena conformità al livello AA, inclusa l’osservanza del criterio 2.4.5. Per le aziende che operano nel competitivo mercato digitale turco — in particolare le piattaforme di e-commerce, le banche e i fornitori di servizi sanitari — il Logo di Accessibilità funge sia da segnale di fiducia per gli utenti con disabilità sia da prova di buona fede regolatoria.

Dal punto di vista pratico, i siti web turchi che servono popolazioni di utenti diversificate traggono notevoli benefici dall’implementazione di molteplici meccanismi di navigazione. La Turchia ha una vasta popolazione di utenti internet anziani e di utenti in regioni con minore alfabetizzazione digitale, entrambi gruppi che beneficiano della ridondanza imposta dal criterio 2.4.5. Una ricerca nel sito con supporto per la lingua turca (inclusa la corretta gestione di caratteri specifici come ı, İ, ş, ğ, ü, ö, ç) combinata con una sitemap HTML chiaramente strutturata rappresenta un’implementazione accessibile e conforme alla normativa che serve bene questo pubblico. Le organizzazioni che mirano a ottenere o mantenere l’Erişilebilirlik Logosu dovrebbero considerare la conformità al criterio 2.4.5 non come un miglioramento opzionale, ma come un requisito fondamentale del proprio programma di accessibilità.