Criteri di successo WCAG · Level A

WCAG 2.4.1: Saltare i blocchi

WCAG 2.4.1 richiede che le pagine web forniscano un meccanismo per saltare i blocchi di contenuto ripetuti, come i menu di navigazione, in modo che le persone che usano la tastiera e le tecnologie assistive possano raggiungere il contenuto principale senza dover scorrere con il tasto Tab ogni singolo link. Questo è un requisito di Livello A, il che significa che rappresenta la base per una navigazione da tastiera accessibile.

Cosa Significa Questa Regola

WCAG 2.4.1 Bypass Blocks afferma: «È disponibile un meccanismo per bypassare blocchi di contenuto ripetuti in più pagine Web.» In termini pratici, questo significa che qualsiasi insieme di link, menu di navigazione, banner o altri blocchi di contenuto che compaiono in modo costante su più pagine deve offrire agli utenti un modo per saltarli e passare direttamente al contenuto unico della pagina corrente.

L’implementazione più ampiamente riconosciuta è un link “salta la navigazione” — un elemento ancora posizionato come primissimo elemento focalizzabile nella pagina, che collega all’area del contenuto principale tramite un identificatore di frammento come #main-content. Tuttavia, le WCAG accettano anche altri meccanismi di bypass, inclusi regioni landmark correttamente strutturate (come gli elementi HTML5 <main>, <nav> e <header> o i loro equivalenti ARIA) e strutture di intestazioni che consentono agli utenti di screen reader di saltare tra le sezioni.

Una pagina supera questo criterio quando è vera almeno una delle seguenti condizioni: è presente e funzionante un link di salto; la pagina utilizza elementi landmark HTML5 significativi che le tecnologie assistive espongono per una navigazione rapida; oppure una scorciatoia da tastiera equivalente o un meccanismo di navigazione interna alla pagina consente agli utenti di bypassare i blocchi ripetuti. Il link di salto può essere nascosto visivamente di default, ma deve diventare visibile al focus da tastiera e deve effettivamente spostare il focus da tastiera sul target quando viene attivato — non solo scorrere il viewport.

Una pagina non supera questo criterio quando: non esiste alcun link di salto, alcuna struttura landmark e nessun altro meccanismo; esiste un link di salto ma è nascosto in modo permanente tramite display:none o visibility:hidden (rendendolo non focalizzabile); l’ancora target del link di salto non esiste nel DOM; oppure il link è presente ma non sposta il focus, costringendo comunque gli utenti da tastiera a scorrere con Tab ogni elemento di navigazione. Le WCAG riconoscono un’eccezione per le pagine in cui non esiste alcun blocco ripetuto — per esempio, un documento a pagina singola senza intestazione di navigazione — ma questa eccezione è limitata e si applica raramente ai siti web reali.

Perché È Importante

Questo criterio influisce direttamente su diversi gruppi di utenti. Gli utenti che usano solo la tastiera — incluse persone con disabilità motorie come lesioni da sforzo ripetitivo, paralisi o tremore — navigano esclusivamente premendo Tab per spostarsi tra gli elementi interattivi. Senza un meccanismo di bypass, devono premere Tab decine di volte solo per raggiungere il primo contenuto unico su ogni singola pagina che visitano. Una tipica barra di navigazione di un sito con da 10 a 20 link moltiplicata per centinaia di visite di pagina diventa un notevole onere fisico e temporale.

Gli utenti di screen reader che sono ciechi o ipovedenti si affidano alle regioni landmark e alle intestazioni per orientarsi e saltare tra le sezioni di una pagina. Sebbene gli screen reader moderni (JAWS, NVDA, VoiceOver) offrano proprie scorciatoie da tastiera per navigare tra landmark e intestazioni, queste scorciatoie funzionano solo quando la pagina è strutturata correttamente. Una pagina senza landmark e senza link di salto impone una lettura lineare di ogni elemento dall’alto, inclusa la navigazione ripetuta, ogni volta che la pagina viene caricata.

Consideriamo uno scenario reale: una cittadina o un cittadino con disabilità visiva in Turchia che visita un portale di e-government per presentare una dichiarazione dei redditi. Il portale ha una barra di navigazione superiore con 18 link, un percorso di navigazione (breadcrumb) con 4 link e una barra laterale secondaria con 12 link — per un totale di 34 pressioni del tasto Tab prima di raggiungere i campi del modulo. Senza un meccanismo di bypass, questa persona deve attraversare tutti e 34 gli elementi su ogni pagina del processo a più fasi. Un link di salto correttamente implementato riduce questo a una singola pressione di tasto.

Anche l’accessibilità cognitiva è un fattore: gli utenti con disturbi dell’attenzione traggono beneficio dalla possibilità di passare direttamente al contenuto rilevante senza dover elaborare elementi di navigazione ripetuti e distraenti. Oltre all’accesso per le persone con disabilità, regioni landmark ben strutturate migliorano la SEO, poiché i crawler dei motori di ricerca utilizzano la struttura del documento per comprendere la gerarchia e la rilevanza dei contenuti. Un’architettura di navigazione accessibile e una chiara struttura di landmark contribuiscono a un migliore indicizzazione e potenzialmente a posizionamenti più alti nei risultati di ricerca.

Regole Axe-core Correlate

  • bypass: Questa regola verifica se la pagina fornisce un qualsiasi meccanismo per bypassare i blocchi di navigazione ripetuti. Axe ispeziona la pagina per verificare la presenza di un link di salto che punti a un’ancora interna esistente, la presenza di ruoli landmark ARIA (role='main', role='navigation', ecc.) o elementi landmark HTML5 (<main>, <nav>, <header>, <footer>, <aside>) e la presenza di attributi ARIA aria-label o aria-labelledby che rendano distinguibili landmark multipli. La regola segnala una violazione quando nessuno di questi meccanismi è presente. Nota che in alcuni casi questa regola richiede una verifica manuale — per esempio, axe può rilevare che esiste un link di salto ma non può confermare automaticamente che sposti il focus da tastiera nella posizione corretta quando viene attivato.
  • skip-link: Questa regola prende di mira specificamente i link di salto e verifica se l’elemento target referenziato dall’attributo href del link di salto (ad esempio, #main-content) esiste effettivamente nel DOM ed è raggiungibile dal focus da tastiera. Se un link di salto punta a un ID inesistente, o se l’elemento target non è focalizzabile (manca un attributo tabindex quando si tratta di un elemento non interattivo), la regola segnala una violazione. Questo intercetta l’errore comune di aggiungere un link di salto in HTML ma dimenticare di aggiungere il corrispondente attributo id all’elemento del contenuto principale.
  • tabindex: Questa regola segnala gli elementi con valori tabindex maggiori di 0, che creano un ordine di tabulazione personalizzato che si discosta dall’ordine naturale del DOM. Sebbene tabindex='0' sia legittimo e necessario per rendere focalizzabili elementi non interattivi (come un target di link di salto <div>), l’uso di tabindex='1', tabindex='2' e così via interrompe la sequenza di Tab attesa sull’intera pagina, il che può rendere i meccanismi di bypass imprevedibili o inefficaci. Gli strumenti automatici possono rilevare la presenza di valori positivi di tabindex, ma un tester umano deve verificare se l’ordine di tabulazione risultante ha senso logico e se il link di salto rimane il primo elemento focalizzabile nella sequenza.

Come Testare

  1. Scansione automatizzata: Esegui axe DevTools (estensione del browser) o Lighthouse (Chrome DevTools > Lighthouse > Accessibility) sulla pagina. Cerca in modo specifico le violazioni sotto le regole bypass, skip-link e tabindex. In axe DevTools, filtra i risultati in base a questi ID di regola. In Lighthouse, controlla la sezione “Navigation” dell’audit di accessibilità. Prendi nota di eventuali elementi “Needs Review” — axe contrassegna alcuni controlli di bypass come richiedenti conferma manuale.
  2. Test da tastiera (tutti i browser): Apri la pagina in un browser senza screen reader attivo. Premi Tab una volta. Conferma che il primissimo elemento messo a fuoco è un link di salto (a questo punto potrebbe apparire visivamente se prima era fuori dallo schermo). Premi Invio per attivare il link di salto. Conferma che il focus da tastiera è stato spostato all’area del contenuto principale — la successiva pressione di Tab dovrebbe raggiungere il primo elemento interattivo all’interno del contenuto principale, non il primo link di navigazione. Se il focus non si sposta, il link di salto è difettoso.
  3. NVDA + Firefox: Avvia NVDA e apri la pagina in Firefox. Premi la scorciatoia Insert+F7 per aprire l’Elenco elementi e controllare i landmark. In alternativa, premi D per saltare tra le regioni landmark e conferma che è presente un landmark main chiaramente etichettato. Premi H per navigare per intestazioni e verifica che la struttura delle intestazioni renda identificabili le sezioni della pagina. Vai con Tab al link di salto e attivalo con Invio, quindi conferma che NVDA annunci contenuti all’interno della regione principale.
  4. VoiceOver + Safari (macOS/iOS): Abilita VoiceOver (Command+F5 su Mac). Usa il Rotor (Control+Option+U) per aprire il menu Landmarks e verifica che compaiano regioni landmark denominate. Vai con Tab al link di salto e premi Invio; conferma che VoiceOver legga il contenuto dell’area principale immediatamente dopo l’attivazione. Su iOS, usa il gesto del Rotor per passare a Landmarks e scorri tra di essi.
  5. JAWS + Chrome: Con JAWS attivo, premi Q per saltare direttamente al landmark del contenuto principale. Verifica che JAWS annunci l’ingresso nella regione principale. Usa Insert+F3 per elencare i landmark e confermare etichette appropriate. Vai con Tab dall’inizio della pagina e verifica che il link di salto venga annunciato per primo, con un nome accessibile come “Skip to main content”.
  6. Verifica del target del focus: Ispeziona il valore href del link di salto (ad esempio, #main-content). Usa gli strumenti di sviluppo del browser per confermare che esista nel DOM un elemento con id='main-content'. Se tale elemento è un <div> o un altro contenitore non interattivo, conferma che abbia tabindex='-1' per renderlo focalizzabile in modo programmatico senza inserirlo nell’ordine naturale di tabulazione.

Come Correggere

Link di salto mancante — Errato

<!-- Navigation appears first with no bypass mechanism -->
<div class='nav-wrapper'>
  <a href='/home'>Home</a>
  <a href='/about'>About</a>
  <a href='/services'>Services</a>
  <a href='/contact'>Contact</a>
</div>
<div class='content'>
  <h1>Welcome</h1>
  <p>Page content here.</p>
</div>

Link di salto mancante — Corretto

<!-- Skip link is the first focusable element; visually hidden until focused -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<nav aria-label='Primary navigation'>
  <a href='/home'>Home</a>
  <a href='/about'>About</a>
  <a href='/services'>Services</a>
  <a href='/contact'>Contact</a>
</nav>

<!-- tabindex='-1' allows the div to receive programmatic focus without
     entering the natural tab order -->
<main id='main-content' tabindex='-1'>
  <h1>Welcome</h1>
  <p>Page content here.</p>
</main>

Link di salto con target inesistente — Errato

<!-- The skip link exists but points to an ID that is not in the DOM -->
<a href='#content' class='skip-link'>Skip to main content</a>

<nav>...navigation links...</nav>

<!-- The id here is 'main', not 'content' — the skip link target is broken -->
<div id='main'>
  <h1>Page Title</h1>
</div>

Link di salto con target inesistente — Corretto

<!-- href value exactly matches the id of the target element -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<nav>...navigation links...</nav>

<!-- id matches the href fragment; tabindex='-1' ensures focus is received -->
<main id='main-content' tabindex='-1'>
  <h1>Page Title</h1>
</main>

Link di salto nascosto permanentemente — Errato

<!-- display:none removes the element from the accessibility tree entirely -->
<a href='#main-content' style='display:none'>Skip to main content</a>

<!-- visibility:hidden also hides from screen readers and keyboard -->
<a href='#main-content' style='visibility:hidden'>Skip to main content</a>

Link di salto nascosto permanentemente — Corretto

<!-- CSS moves the link off-screen visually but keeps it in the tab order.
     On :focus, it becomes visible so sighted keyboard users can see it. -->
<style>
  .skip-link {
    position: absolute;
    left: -9999px;
    top: auto;
    width: 1px;
    height: 1px;
    overflow: hidden;
  }
  .skip-link:focus {
    position: static;
    width: auto;
    height: auto;
    overflow: visible;
  }
</style>

<a href='#main-content' class='skip-link'>Skip to main content</a>

Nessuna struttura landmark — Errato

<!-- Generic divs with no semantic role — screen readers cannot identify regions -->
<div class='header'>...logo and nav...</div>
<div class='sidebar'>...secondary links...</div>
<div class='page-body'>...main content...</div>
<div class='footer'>...footer links...</div>

Nessuna struttura landmark — Corretto

<!-- HTML5 semantic elements expose landmark roles to assistive technologies.
     Multiple nav elements are distinguished with aria-label. -->
<header>
  <nav aria-label='Primary navigation'>...main nav links...</nav>
</header>
<aside aria-label='Related resources'>...secondary links...</aside>
<main id='main-content' tabindex='-1'>...main content...</main>
<footer>
  <nav aria-label='Footer navigation'>...footer links...</nav>
</footer>

Errori Comuni

  • Nascondere il link di salto con display:none o visibility:hidden invece di una tecnica CSS fuori dallo schermo, il che lo rimuove sia dalla visualizzazione sia dall’albero di accessibilità, rendendolo completamente non funzionale per tutti gli utenti.
  • Aggiungere un link di salto con href='#main-content' ma omettere l’attributo corrispondente id='main-content' sull’elemento target, facendo sì che il link non produca alcun effetto quando viene attivato.
  • Puntare il link di salto a un contenitore non interattivo (come un <div> o una <section>) senza aggiungere tabindex='-1', il che significa che i browser faranno scorrere il viewport ma non sposteranno il focus da tastiera sul target.
  • Posizionare il link di salto in un punto qualsiasi diverso dal primissimo elemento focalizzabile nel DOM — per esempio, dopo il logo o dopo il primo link di navigazione — il che ne vanifica lo scopo, poiché gli utenti devono comunque premere Tab oltre del contenuto per raggiungerlo.
  • Usare valori positivi di tabindex (ad esempio, tabindex='1') in qualsiasi punto della pagina, il che riorganizza l’ordine di tabulazione in modi imprevedibili e può spostare il link di salto dalla sua posizione prevista all’inizio.
  • Includere un solo landmark <nav> senza nome quando la pagina ha più regioni di navigazione (navigazione principale, breadcrumb, navigazione nel footer), rendendo impossibile per gli utenti di screen reader distinguerle usando le scorciatoie di navigazione per landmark.
  • Fare affidamento esclusivamente sulla struttura dei landmark senza fornire un link di salto, partendo dal presupposto che tutti gli utenti di screen reader conoscano e usino le scorciatoie per i landmark — gli utenti vedenti che usano solo la tastiera e non usano screen reader non traggono alcun beneficio dai soli landmark e dipendono da un link di salto visibile.
  • Racchiudere l’intero corpo della pagina in un unico elemento <main> che includa navigazione, intestazioni e footer, invece di limitare <main> al contenuto unico della pagina.
  • Usare role='navigation' su un <div> contenente la navigazione senza fornire un aria-label quando esistono più landmark di navigazione, facendo sì che gli screen reader annuncino solo “navigation” senza alcun modo per differenziare le regioni.
  • Implementare correttamente il link di salto in un prototipo HTML statico ma perderlo durante il rendering con un framework JavaScript (ad esempio, React, Angular, Vue) perché il componente del link di salto non è incluso nel layout root o viene rimosso in modo condizionale durante l’hydration lato client.

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à web e mobile basati sugli standard di conformità WCAG 2.1 Livello AA e WCAG 2.2 Livello A. WCAG 2.4.1 Bypass Blocks è un criterio di Livello A, che lo colloca tra i requisiti più fondamentali previsti dalla Circolare — il che significa che rappresenta la soglia al di sotto della quale i servizi digitali di nessun soggetto coperto possono scendere.

La Circolare copre un’ampia gamma di soggetti del settore pubblico e privato. Le istituzioni pubbliche — incluse i ministeri, i comuni, le agenzie statali e gli enti collegati al governo — sono tenute a raggiungere la piena conformità entro un anno dalla data di entrata in vigore della Circolare. I soggetti del settore privato soggetti alla regolamentazione hanno una finestra di conformità di due anni. Le categorie del settore privato coperte includono piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, operatori 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).

Per questi soggetti, la mancata implementazione di WCAG 2.4.1 significa che i loro siti web non sono conformi al livello più basilare dello standard. Un portale governativo, una piattaforma di online banking, un sistema di prenotazione ospedaliera o un flusso di checkout di e-commerce che non disponga di un meccanismo funzionale di salto della navigazione è in violazione diretta dei requisiti della Circolare. Considerato che la navigazione da tastiera è fondamentale per le persone con disabilità motorie e che l’usabilità con screen reader dipende fortemente dalla struttura dei landmark, questo criterio ha un peso significativo negli audit di accessibilità e nelle valutazioni regolatorie.

Le organizzazioni che conducono audit interni di accessibilità o che incaricano valutazioni di terze parti in preparazione alla conformità dovrebbero trattare WCAG 2.4.1 come un elemento di prima verifica — una delle vittorie più facili da implementare e una delle più incisive per le persone che si affidano alla tastiera e alle tecnologie assistive. La mancata risoluzione di questo aspetto può essere citata specificamente nelle revisioni regolatorie come una non conformità di base, con un potenziale impatto sullo stato complessivo di conformità dell’organizzazione ai sensi della Circolare.