Accessibilità da tastiera: come rendere il tuo sito web completamente navigabile da tastiera

Immagina di provare a compilare una domanda di lavoro, prenotare una visita medica o completare un acquisto online — e il tuo mouse non funziona. Non è rotto, è solo irrilevante: navighi esclusivamente premendo Tab, Invio e i tasti freccia. Per milioni di persone in tutto il mondo, questo non è un esperimento mentale. Persone con disabilità motorie, lesioni da sforzo ripetitivo, disabilità visive e persone che si affidano ai lettori di schermo dipendono tutte dalla navigazione da tastiera come principale interfaccia con il web. Eppure le ricerche mostrano costantemente che l’85% dei siti web non offre una navigazione da tastiera adeguata, escludendo questi utenti da attività digitali di base ogni singolo giorno. Se il tuo sito rientra in questa maggioranza, questa guida fa per te.

Chi dipende dalla navigazione da tastiera — e perché è più importante di quanto pensi

L’accessibilità da tastiera non è una preoccupazione di nicchia per una piccola fetta di utenti. La popolazione che ne dipende è più ampia e variegata di quanto la maggior parte degli sviluppatori immagini. Persone con disabilità fisiche che non possono usare il mouse, persone cieche che non possono vedere il puntatore sullo schermo e persone con condizioni croniche come le lesioni da sforzo ripetitivo che dovrebbero limitare l’uso del mouse si affidano tutte alla navigazione da tastiera come porta d’accesso al web. Oltre alla disabilità, molte utenti esperte e molti utenti esperti — sviluppatori, scrittori, professionisti dell’inserimento dati — preferiscono le scorciatoie da tastiera per velocità ed efficienza.

Le persone che usano lettori di schermo rappresentano un altro gruppo importante. I lettori di schermo interpretano e annunciano gli elementi della pagina in base al focus e alla struttura semantica, e gli utenti si muovono tra i contenuti con le sequenze di tasti. Se un sito web non mantiene il focus da tastiera o non supporta un ordine di focus logico, la navigazione tramite lettore di schermo si interrompe completamente. Anche i software di riconoscimento vocale come Dragon NaturallySpeaking generano eventi da tastiera, il che significa che un supporto carente alla tastiera compromette anche la navigazione controllata dalla voce.

Il business case è altrettanto convincente. Secondo i dati disponibili, le persone con disabilità negli Stati Uniti dispongono di quasi mezzo trilione di dollari di reddito disponibile. Quando il tuo sito non è accessibile da tastiera, stai attivamente allontanando una parte significativa di quel mercato. Anche il rischio legale è concreto: l’accessibilità da tastiera è essenziale per la conformità alle WCAG, che sono il punto di riferimento per l’osservanza dell’ADA, della Section 508, dell’European Accessibility Act e della EN 301 549 a livello globale. I soli “keyboard trap” — situazioni in cui un utente rimane bloccato all’interno di un elemento della pagina senza via d’uscita — sono citati come chiari fallimenti WCAG che sono stati al centro di cause legali sull’accessibilità.

Forse il dato più significativo: il 71% delle persone disabili abbandonerà semplicemente un sito web che trova difficile da usare. Non si lamentano. Se ne vanno. E poiché i problemi di accessibilità da tastiera tendono a concentrarsi nei punti di interazione più critici — form, modali, menu di navigazione e flussi di checkout — il danno ricade direttamente sui tuoi tassi di conversione.

Il framework WCAG: cosa richiedono davvero le regole

Le Web Content Accessibility Guidelines (WCAG) organizzano i requisiti relativi alla tastiera principalmente sotto la Linea guida 2.1 — “Rendere tutta la funzionalità disponibile da tastiera”. Capire cosa è richiesto e cosa no è il primo passo verso la conformità. WCAG 2.2, che è diventato lo standard ufficiale W3C il 5 ottobre 2023 e ha aggiunto nove nuovi criteri di successo al framework esistente, è ora lo standard raccomandato per ADA, Section 508 e European Accessibility Act.

I principali criteri di successo relativi alla tastiera che devi conoscere sono:

• SC 2.1.1 Keyboard (Livello A): Tutte le funzionalità devono essere azionabili tramite un’interfaccia da tastiera senza richiedere una tempistica specifica per le singole pressioni di tasto, tranne nei casi in cui la funzione sottostante richieda un input dipendente dal percorso (come il disegno a mano libera). Questo è il livello di base — ogni elemento interattivo deve essere raggiungibile e azionabile da tastiera.
• SC 2.1.2 No Keyboard Trap (Livello A): Se il focus da tastiera può essere spostato su un componente usando la tastiera, il focus deve poter essere spostato anche via da esso usando solo la tastiera. Se è richiesto un metodo non standard per uscire, gli utenti devono esserne informati. I keyboard trap sono un blocco assoluto per chi usa la tastiera.
• SC 2.4.3 Focus Order (Livello A): Se una pagina web può essere navigata in modo sequenziale, l’ordine del focus deve preservare significato e operabilità. Un ordine di tabulazione logico e prevedibile è imprescindibile.
• SC 2.4.7 Focus Visible (Livello AA): Qualsiasi interfaccia utente azionabile da tastiera deve avere una modalità in cui l’indicatore di focus da tastiera sia visibile. Gli utenti devono poter vedere sempre dove si trovano nella pagina.
• SC 2.4.11 Focus Not Obscured (Minimum) (Livello AA — nuovo in WCAG 2.2): Quando un elemento focalizzabile da tastiera riceve il focus, non deve essere completamente nascosto da contenuti creati dall’autore come header fissi o banner per i cookie.
• SC 2.4.12 Focus Not Obscured (Enhanced) (Livello AAA): Una versione più rigorosa che richiede che nessuna parte del componente con focus sia nascosta da contenuti creati dall’autore.
• SC 2.5.8 Target Size (Minimum) (Livello AA — nuovo in WCAG 2.2): I target interattivi devono essere almeno di 24x24 pixel CSS, riducendo gli errori per gli utenti con controllo motorio limitato.
• SC 2.5.7 Dragging Movements (Livello AA — nuovo in WCAG 2.2): Qualsiasi funzionalità che richiede trascinamento deve avere un’alternativa a singolo puntatore — cosa che, per estensione, avvantaggia anche gli utenti da tastiera che non possono eseguire operazioni di drag.

WCAG 2.2 è pienamente retrocompatibile con WCAG 2.1 — aggiunge criteri ma non ne rimuove nessuno (tranne il 4.1.1 Parsing, ora obsoleto). Se il tuo sito soddisfa già WCAG 2.1 AA, devi solo implementare i sei nuovi criteri di Livello AA. Per l’accessibilità da tastiera in particolare, la grande novità è garantire che gli elementi con focus non siano mai completamente oscurati da elementi fissi della pagina — un problema reale molto comune che WCAG 2.1 non affrontava esplicitamente.

Il principio WCAG è semplice da enunciare, impegnativo da implementare: se tutta la funzionalità può essere ottenuta usando la tastiera, può essere utilizzata da chi usa la tastiera, l’input vocale, le tastiere a schermo e una vasta gamma di tecnologie assistive che generano pressioni di tasto simulate. Nessun’altra forma di input ha questa flessibilità o è supportata universalmente.

I fallimenti più comuni dell’accessibilità da tastiera (e cosa li causa)

Le verifiche manuali mostrano costantemente che i problemi di accessibilità da tastiera sono tra le barriere di accessibilità più comuni e dirompenti sul web. In uno studio su larga scala, il 54% delle pagine con form presentava problemi di accessibilità da tastiera che incidevano su azioni critiche come spostarsi con Tab tra i campi del form, chiudere finestre pop-up o premere i pulsanti di invio. I tester sono stati spesso costretti ad abbandonare i carrelli o a ricaricare le pagine dopo essere rimasti bloccati su elementi che non potevano controllare solo con la tastiera.

Le cause principali si concentrano attorno a una manciata di schemi ricorrenti che vale la pena esaminare nel dettaglio.

1. Gestori di eventi solo mouse. L’uso di onmouseover, onmouseout o onclick su elementi <div> senza gestori di eventi equivalenti per la tastiera è uno dei fallimenti più comuni. Un <div> con un gestore di click non è un pulsante — non ha un ruolo implicito da tastiera, non riceve il focus tramite Tab e non risponde a Invio o Spazio. Applicare role='button' tramite ARIA aiuta i lettori di schermo ma richiede comunque di aggiungere manualmente tabindex='0', onkeydown e onkeyup. La soluzione giusta è quasi sempre usare un vero elemento <button>.

2. Contorni di focus soppressi. Uno dei problemi più diffusi è la regola CSS outline: none o outline: 0 applicata globalmente o agli elementi in focus. Spesso i designer rimuovono l’anello di focus predefinito del browser perché appare antiestetico in alcuni temi. Il risultato è che chi usa la tastiera non ha idea di dove si trovi nella pagina. Questo è una violazione diretta di WCAG SC 2.4.7 ed è uno dei problemi più facili da creare — e da risolvere.

3. Keyboard trap in modali, widget e iframe. Le finestre modali che non gestiscono correttamente il focus permettono a Tab di proseguire oltre il modale verso contenuti di sfondo nascosti, rendendo impossibile chiudere il modale tramite tastiera. I widget di terze parti — strumenti di chat, video player, selettori di data, mappe incorporate — sono particolarmente soggetti a questo problema perché la loro gestione interna della tastiera è opaca per te.

4. Ordine di tabulazione illogico. L’ordine predefinito di navigazione da tastiera è determinato dall’ordine del DOM. Quando gli sviluppatori usano CSS Grid, Flexbox o il posizionamento CSS per riordinare la presentazione visiva in modo indipendente dall’ordine del DOM, il focus di Tab salta sullo schermo in modi completamente scollegati dal layout visivo. I valori positivi di tabindex (ad esempio tabindex='2') usati per forzare un ordine specifico peggiorano notevolmente questo problema nella maggior parte dei casi reali.

5. Menu a discesa attivati solo con hover. I menu di navigazione che si aprono solo al passaggio del mouse, senza un trigger da tastiera, lasciano le persone che usano la tastiera bloccate. Questo è uno schema estremamente comune nei menu a discesa realizzati solo con CSS, in cui i sottomenu compaiono su :hover ma non sono mai esposti alla navigazione basata sul focus.

6. Focus non ripristinato dopo interazioni dinamiche. Quando un modale, un pannello a scomparsa o un flyout viene chiuso, il focus deve tornare all’elemento che lo ha attivato. Se non accade — se il focus finisce in cima alla pagina o scompare in una posizione indeterminata — l’utente è completamente disorientato. Le applicazioni dinamiche single-page sono particolarmente vulnerabili a questo problema.

Costruire correttamente l’accessibilità da tastiera: implementazione pratica

Tenendo a mente gli schemi di fallimento, ecco come appare una corretta implementazione nelle aree più importanti di un tipico sito web.

Usa prima l’HTML semantico

Gli elementi HTML nativi sono accessibili da tastiera per impostazione predefinita. I link (<a href>), i pulsanti (<button>), i campi dei form, i select e le textarea partecipano tutti all’ordine di tabulazione, rispondono alle sequenze di tasti standard e comunicano il loro ruolo alle tecnologie assistive — tutto senza una riga di JavaScript aggiuntivo. Un elemento <button> ha automaticamente il ruolo corretto, è accessibile da tastiera, risponde a Invio e Spazio e ha una gestione del focus adeguata integrata. Aggiungere role='button' a un <div> fornisce il ruolo corretto ma richiede comunque di implementare manualmente il supporto da tastiera e la gestione del focus. Preferisci sempre l’HTML semantico.

<!-- Evitare: div non semantico che finge di essere un pulsante -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Corretto: elemento button nativo -->
<button type='button' onclick='doSomething()'>Submit</button>

Sistema i tuoi indicatori di focus

Invece di rimuovere il contorno predefinito del browser, sovrascrivilo con un indicatore di focus personalizzato. WCAG 2.2 SC 2.4.11 richiede che l’area dell’indicatore di focus sia almeno grande quanto un perimetro di 2 pixel CSS di spessore del componente non in focus, con un rapporto di contrasto di almeno 3:1 tra gli stati con e senza focus. Usa la pseudo-classe :focus-visible invece di :focus per mostrare gli indicatori di focus solo per gli utenti da tastiera, senza influire sull’estetica dell’interazione con il mouse.

/* Rimuovere il default solo per sostituirlo con un indicatore migliore */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

Questo approccio ti dà il pieno controllo visivo mantenendo la conformità alle WCAG. Assicurati che il colore del focus abbia un contrasto sufficiente sia rispetto allo sfondo sia rispetto al componente stesso, soprattutto nei siti con tema scuro o sopra le immagini.

Gestisci il focus nelle interazioni dinamiche

Quando i contenuti cambiano in modo dinamico — apertura di un modale, caricamento di nuovi contenuti, rimozione di un elemento — devi gestire il focus in modo programmatico. Quando apri un modale, sposta il focus sul primo elemento focalizzabile al suo interno. Quando lo chiudi, restituisci il focus all’elemento che lo ha attivato. Usa il metodo .focus() di JavaScript per farlo. Per intrappolare correttamente il focus all’interno di un modale, intercetta gli eventi dei tasti Tab e Shift+Tab e fai ciclare il focus tra il primo e l’ultimo elemento focalizzabile all’interno della finestra di dialogo.

// Apertura di un modale: spostare il focus all'interno
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Chiusura di un modale: restituire il focus al trigger
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

Implementa i link per saltare la navigazione

Le persone che usano la tastiera devono premere Tab per passare attraverso ogni elemento interattivo prima del contenuto principale — header, menu di navigazione, barre di ricerca — a ogni singolo caricamento di pagina. I link per saltare la navigazione sono la soluzione: un link visivamente nascosto all’inizio della pagina che diventa visibile al focus e porta gli utenti direttamente all’area del contenuto principale. Sono un requisito WCAG di Livello A e uno dei miglioramenti rapidi più incisivi disponibili.

<!-- Posizionare come primo elemento nel <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Anchor di destinazione sul contenitore del contenuto principale -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>

/* Mostrare il link di salto solo al focus da tastiera */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

Costruisci menu di navigazione accessibili

I menu di navigazione con sottomenu a discesa richiedono particolare attenzione. Il modello di interazione da tastiera corretto per un menu di navigazione è: Tab si sposta tra gli elementi di primo livello; Invio o Spazio apre un sottomenu; i tasti freccia navigano all’interno del sottomenu; Esc chiude il sottomenu e riporta il focus al trigger. Usa gli attributi ARIA per comunicare lo stato. I menu che si aprono solo con hover, senza un trigger da tastiera, non sono accessibili e devono essere corretti.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

Usa aria-expanded='false' e aria-expanded='true' attivati tramite JavaScript per comunicare lo stato aperto/chiuso. Usa aria-haspopup='true' per segnalare che l’attivazione del pulsante rivela un sottomenu. Assicurati che il tasto Esc chiuda il sottomenu e riporti il focus al pulsante che lo ha attivato.

Gestisci correttamente tabindex

Ci sono tre valori significativi di tabindex e ognuno ha uno scopo distinto. tabindex='0' aggiunge un elemento non interattivo all’ordine naturale di tabulazione — usalo quando hai davvero bisogno che un elemento non focalizzabile (come il contenitore di un widget personalizzato) riceva il focus. tabindex='-1' rimuove un elemento dall’ordine di tabulazione ma gli consente di ricevere il focus in modo programmatico tramite .focus() — essenziale per i target dei modali e le destinazioni dei link per saltare la navigazione. I valori positivi di tabindex (come tabindex='1' o tabindex='5') sovrascrivono l’ordine naturale in modi che quasi sempre causano più problemi che benefici; evitali del tutto e correggi invece l’ordine del DOM.

ARIA: uno strumento potente, non una soluzione magica

Gli attributi Accessible Rich Internet Applications (ARIA) estendono la semantica dell’HTML per aiutare le tecnologie assistive a comprendere i componenti personalizzati che l’HTML nativo non copre — tab, accordion, tree view, caroselli, combo box. Gli attributi ARIA possono fornire contesto aggiuntivo, ma dovrebbero integrare — non sostituire — l’HTML semantico. Un errore comune e pericoloso è ricorrere ad ARIA prima di considerare se un elemento HTML nativo potrebbe svolgere lo stesso compito.

La prima regola di ARIA è: non usare ARIA se un elemento o attributo HTML nativo può svolgere lo stesso compito. La seconda regola: nessuna ARIA è meglio di una ARIA sbagliata. Un markup ARIA errato — per esempio, applicare role='menu' senza la gerarchia corretta di figli con role='menuitem', o usare aria-hidden='true' su un elemento che riceve il focus — può danneggiare attivamente l’accessibilità invece di migliorarla.

Quando ARIA è davvero necessaria, gli attributi più utili per le interazioni da tastiera sono: aria-expanded per comunicare lo stato aperto/chiuso sugli elementi comprimibili; aria-controls per collegare un trigger al contenuto che controlla; aria-haspopup per segnalare che un pulsante apre un menu o una finestra di dialogo; aria-modal='true' sugli elementi di dialogo per indicare che i contenuti di sfondo sono inattivi; e le regioni aria-live (polite per i messaggi di stato, assertive per gli avvisi urgenti) per annunciare i cambiamenti dinamici dei contenuti alle persone che usano lettori di schermo senza spostare il focus.

Una considerazione sottile ma importante: lettori di schermo come NVDA e JAWS usano proprie scorciatoie da tastiera — per esempio, premere H in NVDA sposta l’utente all’intestazione successiva nella pagina. Gli sviluppatori dovrebbero evitare di creare scorciatoie applicative personalizzate che entrino in conflitto con questi comandi delle tecnologie assistive.

Testare l’accessibilità da tastiera

Il test più efficace che puoi eseguire subito non richiede strumenti: scollega il mouse e naviga nel tuo sito usando solo la tastiera. Premi Tab per spostarti in avanti tra gli elementi interattivi, Shift+Tab per tornare indietro, Invio per attivare link e pulsanti, Spazio per attivare e disattivare le caselle di controllo e attivare i pulsanti, Esc per chiudere modali e menu e i tasti freccia per navigare all’interno dei componenti. Chiediti: riesci a raggiungere ogni elemento interattivo? Riesci a vedere sempre dove ti trovi? Riesci a completare ogni percorso utente critico senza rimanere bloccato?

Gli strumenti automatici possono individuare una parte significativa dei problemi di accessibilità da tastiera — in particolare etichette mancanti, pulsanti vuoti e alcuni problemi di gestione del focus. Strumenti come axe DevTools, WAVE e Lighthouse sono ottimi primi passaggi. Tuttavia, gli strumenti automatici rilevano solo circa il 40% dei problemi WCAG. La visibilità del focus, l’ordine logico del focus e la corretta gestione degli stati ARIA richiedono tutti una valutazione manuale umana. Per una valutazione davvero approfondita, combina la scansione automatizzata con test manuali solo da tastiera su più browser e includi test con lettori di schermo come NVDA (Windows), JAWS (Windows) o VoiceOver (macOS/iOS).

Alcuni scenari specifici da testare manualmente ogni volta che rilasci un nuovo componente o una nuova pagina: riesci ad aprire e chiudere ogni menu a discesa, modale e accordion usando solo Tab, Invio ed Esc? Quando un modale si chiude, il focus torna al trigger? Il link per saltare la navigazione appare e funziona alla prima pressione di Tab? Ci sono punti in cui il focus di Tab scompare in un elemento senza indicatore visibile? Gli header fissi o i banner per i cookie oscurano gli elementi con focus mentre ti sposti con Tab nella pagina?

Per i team che costruiscono librerie di componenti, la WAI-ARIA Authoring Practices Guide (APG) pubblicata dal W3C è il riferimento definitivo per i modelli di interazione da tastiera su decine di tipi di widget — da accordion e caroselli a selettori di data e tree view. Ogni modello specifica esattamente quali tasti devono essere supportati e quale dovrebbe essere il comportamento atteso.

Header fissi, footer fissi e oscuramento del focus

Uno dei requisiti nuovi più rilevanti in pratica in WCAG 2.2 è il Criterio di successo 2.4.11: Focus Not Obscured. Affronta un problema talmente comune da definire praticamente il web moderno: barre di navigazione fisse, banner per il consenso ai cookie, widget di chat e footer fissi che si sovrappongono ai contenuti della pagina. Quando una persona che usa la tastiera passa con Tab a un elemento che viene fatto scorrere dietro uno di questi livelli fissi, l’elemento con focus diventa invisibile — l’utente non può vedere con cosa sta interagendo.

La soluzione richiede coordinamento tra CSS e JavaScript. Quando un elemento riceve il focus, il browser deve farlo scorrere in un’area visibile. Ma un header fisso con position: fixed e un’altezza di, diciamo, 80px significa che i primi 80px della viewport sono occupati in modo permanente. Lo scroll padding CSS può compensare questo:

html {
  /* Altezza dell'header fisso + un piccolo margine */
  scroll-padding-top: 96px;
}

Questo indica al browser di compensare l’ancoraggio dello scroll della quantità specificata, così quando fa scorrere automaticamente un elemento con focus in vista, tiene conto dell’header fisso. Potresti aver bisogno anche di un equivalente scroll-padding-bottom se hai un footer fisso. Per i banner dei cookie o gli overlay che compaiono e scompaiono, assicurati che abbiano valori di z-index che non coprano l’elemento con focus, o regola dinamicamente lo scroll padding quando il banner è visibile.

Punti chiave

• L’HTML semantico è la tua prima mossa migliore. Gli elementi nativi come <button>, <a> e i controlli dei form sono accessibili da tastiera per impostazione predefinita. Ogni widget personalizzato costruito con div ti costa accessibilità che dovrai poi ricostruire manualmente con ARIA e JavaScript.
• Non sopprimere mai gli indicatori di focus senza sostituirli. La regola globale outline: none è una delle cose più dannose che puoi inserire in un foglio di stile. Usa :focus-visible per fornire un anello di focus stilizzato e ad alto contrasto che soddisfi i requisiti minimi di dimensione e contrasto di WCAG 2.2.
• Gestisci il focus in modo programmatico per ogni interazione dinamica. Modali, pannelli a scomparsa, notifiche toast e cambiamenti dinamici dei contenuti richiedono tutti una gestione esplicita del focus — spostare il focus all’interno e restituirlo alla chiusura. Senza questo, chi usa la tastiera perde la propria posizione ogni volta che l’interfaccia cambia.
• Aggiungi un link per saltare la navigazione in cima a ogni pagina. Richiede meno di 20 righe di codice e migliora drasticamente l’esperienza per chi usa la tastiera e altrimenti dovrebbe passare con Tab attraverso l’intero header e la navigazione a ogni caricamento di pagina.
• Testa con la tastiera prima di rilasciare. Gli strumenti automatici rilevano solo una frazione dei problemi di accessibilità da tastiera. Una verifica di dieci minuti usando solo la tastiera sui tuoi percorsi utente più critici farà emergere blocchi reali che nessuno scanner troverà — e può essere eseguita da qualsiasi sviluppatrice o sviluppatore del team senza formazione specialistica.