WCAG 2.1.1: Tastiera

Cosa Significa Questa Regola

WCAG 2.1.1 (Keyboard) stabilisce che ogni funzionalità in una pagina web o applicazione deve essere utilizzabile tramite un’interfaccia da tastiera. Questo significa che se un utente può fare clic su un pulsante, trascinare un elemento, passare il mouse per rivelare un menu o interagire con qualsiasi altro elemento usando il mouse, deve poter eseguire la stessa identica azione usando solo input da tastiera — tipicamente i tasti Tab, Shift+Tab, Invio, Barra spaziatrice e le frecce direzionali.

Il criterio si applica a tutti gli elementi interattivi: link, pulsanti, controlli di form, widget personalizzati, finestre modali, menu a discesa, fisarmoniche (accordion), caroselli, selettori di data, interfacce drag-and-drop, interazioni basate su canvas e qualsiasi altro componente che risponde all’input dell’utente. Se un contenuto richiede che l’utente esegua un tracciato di disegno (in cui il tracciato stesso è l’input, non solo il punto finale), questa è l’unica eccezione formalmente riconosciuta in WCAG. Al di fuori di questa stretta eccezione, ogni altra funzionalità deve essere accessibile da tastiera.

Un superamento (pass) significa che un utente che usa solo la tastiera può raggiungere ogni elemento interattivo tramite la navigazione con Tab o con i tasti freccia, attivarlo con Invio o Barra spaziatrice e completare l’azione prevista senza dover usare il mouse in nessuna fase. Un fallimento (fail) si verifica quando si applica una delle seguenti condizioni: un elemento interattivo non riceve affatto il focus; il focus viene ricevuto ma l’elemento non può essere attivato; una funzione è attivata esclusivamente da un evento del mouse come onmouseover o ondblclick senza un equivalente da tastiera; oppure un contenitore scrollabile non è raggiungibile da tastiera, intrappolando al suo interno il contenuto.

È importante distinguere WCAG 2.1.1 da WCAG 2.1.2 (No Keyboard Trap). Il criterio 2.1.1 garantisce che gli utenti da tastiera possano raggiungere e usare tutto; il criterio 2.1.2 garantisce che gli utenti da tastiera non rimangano mai bloccati all’interno di un componente. Entrambi devono essere soddisfatti per una piena conformità di Livello A.

Perché È Importante

L’accessibilità da tastiera non è una preoccupazione di nicchia. Si stima che 1 adulto su 4 negli Stati Uniti viva con qualche forma di disabilità, e le disabilità motorie — incluse condizioni come il morbo di Parkinson, la sclerosi multipla, lesioni al midollo spinale, lesioni da sforzo ripetitivo (RSI), differenze agli arti e tremori — spesso impediscono agli utenti di usare un mouse standard o un touchscreen. Questi utenti si affidano interamente a tastiere, controlli a interruttore, dispositivi sip-and-puff, puntatori a testa o altre tecnologie assistive che in ultima analisi emulano l’input da tastiera a livello di sistema operativo.

Le persone cieche e ipovedenti che usano screen reader come NVDA, JAWS o VoiceOver navigano interamente tramite tastiera. Se un elemento non è raggiungibile da tastiera, lo screen reader non lo annuncerà mai, rendendo il contenuto completamente invisibile per quell’utente. Secondo l’Organizzazione Mondiale della Sanità, almeno 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva da vicino o da lontano.

Consideriamo uno scenario concreto: una persona con artrite reumatoide avanzata in entrambe le mani visita una pagina di checkout di un sito di e-commerce. Il selettore del metodo di pagamento, sviluppato su misura, è implementato come una serie di elementi <div> stilizzati che rispondono solo ai clic del mouse. L’utente può usare Tab per raggiungere il contenitore, ma nessuna opzione individuale riceve il focus e premere Invio non produce alcun effetto. Non può completare l’acquisto. Questo non è un semplice disagio — è una completa esclusione da una transazione commerciale, e rappresenta sia un rischio legale sia una significativa perdita di ricavi per l’azienda.

Oltre alla disabilità, l’accessibilità da tastiera avvantaggia gli utenti esperti che preferiscono le scorciatoie da tastiera per velocità, gli utenti in contesti aziendali o governativi in cui l’uso del mouse è limitato dalle policy, e gli utenti con dispositivi di input non standard. Inoltre, è positivamente correlata a strutture HTML pulite e semantiche che i motori di ricerca analizzano in modo più affidabile, contribuendo a migliori prestazioni SEO e a una maggiore manutenibilità del codice nel lungo periodo.

Regole Axe-core Correlate

• scrollable-region-focusable: Questa regola verifica se ogni elemento che ha contenuto in overflow (cioè è scrollabile) è raggiungibile tramite tastiera. Quando un contenitore ha proprietà CSS come overflow: auto o overflow: scroll, gli utenti vedenti che usano il mouse possono scorrerlo con la rotellina o il trackpad. Gli utenti da tastiera, invece, devono poter usare Tab per entrare nel contenitore o i tasti freccia per scorrerlo. La regola segnala le regioni scrollabili che non hanno l’attributo tabindex e nessun elemento figlio naturalmente focalizzabile, il che significa che un utente che usa solo la tastiera non avrebbe modo di accedere al contenuto in overflow. Il rilevamento automatico è affidabile in questo caso perché axe può ispezionare gli stili calcolati e il DOM per identificare gli elementi con overflow scrollabile che non hanno capacità di focus da tastiera.
• server-side-image-map: Questa regola segnala l’uso di image map lato server — elementi HTML <img> con l’attributo ismap. Le image map lato server inviano al server le coordinate in pixel del clic del mouse per determinare quale link è stato attivato. Poiché l’azione dipende interamente da coordinate in pixel derivate da un dispositivo di puntamento, non esiste un meccanismo equivalente da tastiera. A differenza delle image map lato client (che usano gli elementi <map> e <area> e possono essere rese accessibili da tastiera), le image map lato server sono fondamentalmente incompatibili con la navigazione solo da tastiera. Axe segnala qualsiasi elemento <img ismap> come un errore di accessibilità da tastiera. La verifica manuale dovrebbe confermare se l’image map è l’unico modo per accedere alla navigazione o alla funzionalità sottostante.

È fondamentale comprendere che strumenti automatici come axe-core possono rilevare solo un sottoinsieme dei problemi di accessibilità da tastiera. Molte violazioni richiedono test manuali perché coinvolgono listener di eventi JavaScript personalizzati, gestione dinamica del focus o pattern di interazione complessi che l’analisi statica non può valutare completamente. Per esempio, un pulsante implementato come <div> con un listener di evento click può ricevere il focus tramite tabindex='0' ma non rispondere alla pressione dei tasti Invio o Barra spaziatrice — un errore che axe non può sempre rilevare senza eseguire l’interazione.

Come Testare

1. Scansione automatizzata con axe DevTools o Lighthouse: Installa l’estensione browser axe DevTools per Chrome o Firefox. Vai alla pagina da testare ed esegui una scansione dell’intera pagina. Filtra i risultati per le regole etichettate con wcag2a e keyboard. Cerca in particolare violazioni di scrollable-region-focusable e server-side-image-map. In Lighthouse (Chrome DevTools), esegui un audit di Accessibilità e rivedi la categoria “Keyboard”. Nota che questi strumenti evidenzieranno i problemi strutturali più evidenti ma non rileveranno tutti i problemi relativi a widget personalizzati.
2. Test manuale di navigazione da tastiera: Scollega o metti da parte completamente il mouse. A partire dalla barra degli indirizzi del browser, premi ripetutamente Tab per spostarti in avanti tra tutti gli elementi focalizzabili della pagina. Premi Shift+Tab per spostarti all’indietro. Per ogni elemento interattivo — link, pulsanti, campi di input, menu a discesa personalizzati, modali, slider — verifica che: (a) riceva un indicatore di focus visibile; (b) premere Invio o Barra spaziatrice lo attivi come previsto; (c) qualsiasi dialogo o pannello risultante possa essere navigato e chiuso tramite tastiera. Usa i tasti freccia all’interno dei widget che implementano pattern compositi (menu, liste di tab, gruppi di radio button, listbox).
3. Test con screen reader + tastiera con NVDA e Firefox: Avvia NVDA (gratuito, Windows) e apri Firefox. Usa la Browse Mode di NVDA (tasti freccia) per leggere la pagina e identificare tutti gli elementi interattivi. Passa alla Focus Mode (Insert+Barra spaziatrice o automatica sui campi di form) per interagire con i controlli. Verifica che i widget personalizzati annuncino il loro ruolo, stato e nome, e che tutta la funzionalità possa essere completata senza mouse. Testa eventuali contenitori scrollabili cercando di raggiungerli con Tab e usando i tasti freccia per scorrere.
4. Test con screen reader VoiceOver e Safari (macOS/iOS): Attiva VoiceOver (Command+F5 su macOS). Usa VO+Freccia destra per navigare linearmente nella pagina. Usa Tab per spostarti tra gli elementi interattivi. Conferma che le regioni scrollabili siano raggiungibili e che nessuna funzionalità richieda un gesto di swipe o un’interazione con puntatore senza un’alternativa accessibile da tastiera.
5. Test con JAWS e Chrome: Con JAWS in esecuzione, apri Chrome e vai alla pagina. Usa il Cursore Virtuale di JAWS per esplorare il contenuto e il tasto Tab per spostarti tra gli elementi interattivi. Testa in modo specifico qualsiasi widget JavaScript personalizzato — fisarmoniche, caroselli, finestre modali, select personalizzati — raggiungendoli con Tab e tentando di usarli completamente tramite tastiera. Registra qualsiasi elemento che riceve il focus ma non può essere attivato, o qualsiasi funzionalità raggiungibile solo tramite hover del mouse.
6. Test specifico per le regioni scrollabili: Identifica tutti i contenitori nella pagina con barre di scorrimento visibili o che contengono più contenuto rispetto alla loro area visibile. Prova a raggiungere ciascun contenitore con Tab. Se Tab non sposta il focus all’interno del contenitore e non ci sono elementi figli focalizzabili, il contenitore è probabilmente un errore di accessibilità da tastiera. Prova a premere i tasti freccia mentre il contenitore o un elemento vicino ha il focus per vedere se lo scorrimento è possibile.

Come Correggere

Scenario 1: Contenitore Scrollabile — Errato

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenario 1: Contenitore Scrollabile — Corretto

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenario 2: Image Map Lato Server — Errato

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Scenario 2: Image Map Lato Server — Corretto

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Scenario 3: Widget Personalizzato che Usa Solo Eventi del Mouse — Errato

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Scenario 3: Widget Personalizzato che Usa Solo Eventi del Mouse — Corretto

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Scenario 4: Menu a Discesa Solo su Hover — Errato

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Scenario 4: Menu a Discesa Solo su Hover — Corretto

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Errori Comuni

• Usare onclick come unico gestore di eventi su un elemento non nativo senza aggiungere un corrispondente gestore onkeydown o onkeyup — i clic del mouse attivano onclick ma l’attivazione da tastiera su un <div> o <span> no.
• Aggiungere tabindex='0' a un elemento interattivo personalizzato ma dimenticare di aggiungere role='button' (o il ruolo appropriato), il che significa che gli screen reader non comunicano lo scopo dell’elemento all’utente.
• Costruire una navigazione a discesa che si basa esclusivamente sulla pseudo-classe CSS :hover senza un toggle da tastiera gestito da JavaScript, rendendo i sottomenu invisibili e irraggiungibili per gli utenti da tastiera.
• Implementare interfacce drag-and-drop — liste ordinabili, kanban board, aree di upload file — senza un meccanismo alternativo accessibile da tastiera, come comandi di spostamento attivati da tastiera o un controllo separato per riordinare.
• Creare contenitori scrollabili (come riquadri con termini di servizio, finestre di chat o tabelle di dati all’interno di wrapper ad altezza fissa) senza tabindex='0', impedendo agli utenti da tastiera di scorrere per visualizzare tutto il contenuto.
• Usare <img ismap> per componenti di navigazione ereditati da codebase legacy senza sostituirli con image map lato client o link di navigazione standard.
• Applicare tabindex='-1' a elementi interattivi per rimuoverli dall’ordine naturale di Tab senza fornire una strategia di gestione del focus programmata, con il risultato di controlli permanentemente irraggiungibili da tastiera.
• Attivare funzionalità esclusivamente sugli eventi mouseenter, mouseleave o mousemove (tooltip, anteprime, menu contestuali) senza equivalenti eventi focus, blur o alternative basate sulla tastiera.
• Dare per scontato che una finestra modale gestisca automaticamente il focus — non spostare il focus all’interno della modale quando si apre e non restituire il focus all’elemento che l’ha attivata quando si chiude, lasciando gli utenti da tastiera disorientati nella pagina.
• Impostare pointer-events: none in CSS su un elemento che dovrebbe essere accessibile da tastiera, il che, pur non influenzando direttamente il comportamento da tastiera, è spesso abbinato a pattern JavaScript che bloccano anche l’interazione da tastiera.

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 allineati a WCAG 2.1 Livello AA. WCAG 2.1.1 (Keyboard) è un criterio di Livello A, che lo colloca nel livello di priorità più alto tra quelli richiesti. La conformità di Livello A è la soglia minima assoluta — se un sito non soddisfa i criteri di Livello A, è considerato non accessibile indipendentemente da qualsiasi altro miglioramento effettuato.

In base alla circolare, le tempistiche di conformità sono differenziate per tipo di ente: le istituzioni pubbliche e le agenzie governative devono raggiungere la conformità entro un anno dalla data di pubblicazione della circolare, mentre le entità del settore privato coperte dal regolamento hanno due anni per conformarsi.

Le entità coperte dalla Circolare Presidenziale 2025/10 includono un’ampia sezione trasversale dei servizi digitali turchi: piattaforme di e-commerce, istituzioni pubbliche e ministeri, 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).

Per tutte queste entità, il mancato rispetto di WCAG 2.1.1 significa che gli utenti che dipendono dalla tastiera — inclusi cittadini con disabilità motorie, persone anziane e utenti di screen reader — non possono accedere ai loro servizi digitali principali. Questo costituisce una violazione diretta del regolamento. In termini pratici, un sito di e-commerce in cui il flusso di checkout non può essere completato da tastiera, o un portale pazienti di un ospedale in cui la prenotazione degli appuntamenti richiede l’uso del mouse, sarebbe in violazione dei requisiti della circolare.

Le organizzazioni soggette alla circolare dovrebbero condurre un audit di accessibilità da tastiera come primo passo nel loro programma di remediation dell’accessibilità. Poiché i problemi relativi a WCAG 2.1.1 sono spesso di natura architetturale — radicati nella scelta degli elementi HTML, nei pattern di associazione degli eventi e nelle impostazioni predefinite dei framework di componenti — la loro correzione può richiedere modifiche a livello di codice piuttosto che semplici regolazioni di configurazione. L’SDK overlay di Accsible può aiutare a individuare e correggere le lacune più comuni di accessibilità da tastiera a livello di JavaScript, ma i team dovrebbero anche perseguire correzioni strutturali nel loro codice sorgente per ottenere una conformità robusta e verificabile che soddisfi la revisione regolatoria.