WCAG 2.1.3: Tastiera (nessuna eccezione)

Cosa Significa Questa Regola

WCAG 2.1.3 — Tastiera (Senza Eccezioni) è un criterio di successo di livello AAA in WCAG 2.1 e 2.2 che estende WCAG 2.1.1 (Tastiera, Livello A) eliminando ogni deroga. In particolare, afferma: Tutte le funzionalità del contenuto sono operabili tramite un’interfaccia tastiera senza richiedere tempi specifici per singole pressioni di tasti. La distinzione fondamentale rispetto a 2.1.1 è l’assenza della clausola di eccezione che esenta le funzionalità in cui la funzione sottostante richiede un input che dipende dal percorso del movimento dell’utente, non solo dai punti finali.

In base a 2.1.1, gli sviluppatori possono legittimamente escludere dal supporto da tastiera funzionalità come canvas per il disegno a mano libera, strumenti di pittura basati su gesture o interfacce di drag sensibili al percorso, perché il percorso esatto del puntatore dell’utente determina il risultato. WCAG 2.1.3 elimina completamente questa eccezione. Secondo questo criterio, ogni singola funzione—inclusi disegno, trascinamento, gesture dipendenti dal percorso e qualsiasi interazione che storicamente si è basata sul movimento del puntatore—deve essere accessibile tramite tastiera. Ciò significa che gli sviluppatori devono fornire meccanismi alternativi da tastiera (ad esempio, una toolbar accessibile con strumenti per le forme, modalità di disegno controllate da tastiera o alternative basate su form) anche per attività a mano libera o dipendenti dal percorso.

Un superamento richiede che ogni operazione sulla pagina possa essere avviata, gestita e completata usando solo la tastiera. Questo include gestione del focus, finestre modali, riordinamento drag-and-drop, slider personalizzati, strumenti di disegno su canvas, interazioni con mappe, navigazione nei caroselli e controlli di riproduzione video. Non deve esserci alcuna trappola da tastiera (coperta anche da 2.1.2), nessuna funzione che possa essere attivata solo tramite clic, hover o gesture touch senza un percorso equivalente da tastiera, e nessuna dipendenza dai percorsi del puntatore del mouse.

Un fallimento si verifica quando qualsiasi funzionalità—indipendentemente da quanto di nicchia o secondaria possa sembrare—non può essere raggiunta o completata tramite la sola tastiera. Poiché questo criterio non prevede eccezioni, anche una sola funzione non accessibile da tastiera costituisce un fallimento completo, rendendolo uno degli standard più esigenti in WCAG.

Perché È Importante

L’accessibilità da tastiera è fondamentale per le persone con disabilità motorie che non possono usare un dispositivo di puntamento. Persone con condizioni come il morbo di Parkinson, tetraplegia, paralisi cerebrale, lesioni da sforzo ripetitivo o differenze agli arti spesso si affidano esclusivamente a una tastiera fisica, a un dispositivo a sensore, a un controller a soffio e aspirazione o a tecnologie di eye-tracking che emulano l’input da tastiera. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone nel mondo vivono con una forma significativa di disabilità, e le disabilità motorie o fisiche rappresentano una parte sostanziale di questa popolazione. Solo in Turchia, i dati dell’Istituto di Statistica Turco (TÜİK) indicano che oltre 8,5 milioni di persone riportano almeno una forma di limitazione funzionale.

Oltre alla disabilità motoria, l’accessibilità da tastiera avvantaggia persone cieche e ipovedenti che navigano con screen reader come NVDA, JAWS o VoiceOver—tutti basati su comandi da tastiera per attraversare e interagire con i contenuti web. Persone con condizioni fotosensibili possono evitare i touchscreen, e persone con disabilità cognitive spesso traggono beneficio dalla navigazione prevedibile e lineare che l’interazione da tastiera offre.

Consideriamo uno scenario concreto reale: una piattaforma di graphic design che offre uno strumento di disegno vettoriale a mano libera. In base a WCAG 2.1.1, questo potrebbe essere esentato perché il percorso del puntatore definisce la forma. In base a WCAG 2.1.3, la piattaforma deve fornire un’alternativa—magari una libreria di forme, una serie di punti di ancoraggio controllati da tastiera o un editor di percorsi SVG basato su testo—così che una persona con disabilità motoria possa comunque creare grafica vettoriale senza mouse. Non farlo esclude una parte significativa di professionisti creativi che si affidano esclusivamente alla tastiera.

Da una prospettiva di usabilità e SEO, interfacce correttamente accessibili da tastiera presentano in genere una gestione del focus più pulita, un ordine di tabulazione più logico e gerarchie DOM ben strutturate—tutti elementi che contribuiscono a una migliore indicizzabilità e a un’esperienza utente di qualità superiore per tutti, inclusi gli utenti esperti che preferiscono le scorciatoie da tastiera per velocità.

Regole Axe-core Correlate

WCAG 2.1.3 richiede test manuali. A differenza di molti criteri WCAG, gli strumenti automatici non possono rilevare in modo affidabile le violazioni di questo criterio perché:

• Il rilevamento di funzionalità dipendenti dal percorso va oltre l’analisi statica: Axe-core e Lighthouse ispezionano il DOM alla ricerca di pattern strutturali—tabindex mancanti, attributi role assenti o gestione del focus difettosa—ma non possono simulare un utente che tenta ogni funzione su una pagina per determinare se esiste un’alternativa da tastiera. Un elemento canvas può essere presente nel DOM senza attributi ARIA, e tuttavia una toolbar accessibile da tastiera nelle vicinanze può soddisfare pienamente 2.1.3. Al contrario, un pulsante apparentemente normale può attivare un’azione JavaScript che a sua volta lancia un widget utilizzabile solo con il mouse, che gli strumenti automatici non segnaleranno mai. L’equivalenza logica delle alternative da tastiera rispetto ai percorsi guidati dal mouse richiede un giudizio umano.
• Nessuna regola axe-core dedicata mappa a 2.1.3: Le regole axe più vicine—come scrollable-region-focusable (che verifica se le aree di contenuto scrollabili possono ricevere il focus da tastiera) e tabindex (che segnala valori tabindex positivi che interrompono l’ordine naturale del focus)—affrontano aspetti correlati ma più ristretti in 2.1.1 e 2.4.3. Non valutano e non possono valutare se tutte le funzionalità, incluse le operazioni sensibili al percorso, hanno un equivalente da tastiera.
• Le verifiche dei widget interattivi richiedono interazione in runtime: Componenti drag-and-drop personalizzati, editor basati su canvas e caroselli guidati da gesture rivelano la loro inaccessibilità da tastiera solo quando un tester tenta effettivamente di usarli senza mouse. La scansione DOM statica di axe-core non può attivare i listener di eventi, osservare la perdita di focus durante operazioni asincrone o valutare se un’operazione di drag può essere completata tramite i tasti freccia e Invio/Barra spaziatrice.
• Cosa cercare durante l’audit manuale: I tester dovrebbero cercare in particolare elementi canvas usati per disegno o interazione, liste drag-and-drop o aree di upload file, controlli di mappe o visualizzazioni dati personalizzate, slider basati sul tempo e qualsiasi componente che risponde a eventi mousemove, pointermove o gesture touch senza gestori di eventi da tastiera corrispondenti.

Come Testare

1. Esegui una scansione automatizzata di base: Usa axe DevTools (estensione del browser o CLI) o Google Lighthouse sulla tua pagina per identificare eventuali problemi di accessibilità da tastiera più evidenti—elementi non focalizzabili, trappole da tastiera o elementi con pointer-events: none che dovrebbero essere interattivi. Sebbene questi strumenti non rilevino direttamente violazioni di 2.1.3, mettono in evidenza problemi correlati e stabiliscono una base pulita prima dell’inizio dei test manuali.
2. Catalogare tutte le funzionalità interattive: Prima dei test, crea un inventario completo di ogni componente interattivo sulla pagina: pulsanti, link, form, modali, accordion, caroselli, mappe, strumenti canvas, aree drag-and-drop, dropdown personalizzati, selettori di data, lettori video e qualsiasi widget che risponde a eventi di mouse o touch. Questo inventario diventa la tua checklist di test.
3. Test di navigazione solo da tastiera: Scollega o disabilita il mouse. Usa Tab e Shift+Tab per spostare il focus, Invio e Barra spaziatrice per attivare i controlli, i tasti freccia per i widget compositi (menu, slider, tab, gruppi di radio button) ed Esc per chiudere le finestre di dialogo. Tenta di completare ogni funzione nel tuo inventario. Annota qualsiasi funzione che non puoi avviare, completare o uscire usando solo la tastiera.
4. Test con screen reader NVDA + Firefox: Avvia NVDA (Windows) con Firefox. Naviga usando il cursore virtuale (H per le intestazioni, B per i pulsanti, F per i campi dei form, Tab per gli elementi interattivi). Tenta ogni funzione. Ascolta ruolo, nome e stato annunciati. Identifica qualsiasi area interattiva irraggiungibile o che non produce alcun annuncio udibile.
5. Test con screen reader JAWS + Chrome: Usa JAWS su Windows con Chrome. Usa il cursore virtuale di JAWS e la Forms Mode (attivabile con Invio). Verifica che tutte le funzionalità possano essere azionate e che il focus sia gestito correttamente dopo ogni interazione—soprattutto dopo l’apertura di finestre modali o il caricamento di contenuti AJAX.
6. Test con screen reader VoiceOver + Safari (macOS/iOS): Abilita VoiceOver (Command + F5 su macOS). Usa Control + Option + Frecce per navigare. Su iOS, usa le gesture di swipe. Conferma che tutte le funzioni siano raggiungibili e operabili. Presta particolare attenzione ai widget touch personalizzati che potrebbero non avere equivalenti da tastiera nella versione desktop.
7. Audit delle funzionalità dipendenti dal percorso: Per qualsiasi canvas di disegno, interazione con mappe o componente guidato da gesture, verifica se esiste un meccanismo alternativo da tastiera. Tenta di creare una forma, riordinare un elemento di una lista o spostare una mappa usando solo i controlli da tastiera. Se non esiste alcun percorso da tastiera, si tratta di un fallimento diretto di 2.1.3.
8. Verifica della visibilità del focus: Durante la navigazione solo da tastiera, conferma che il focus sia sempre visibile sullo schermo e ordinato in modo logico. Un focus invisibile o che salta in posizioni inattese è un problema di usabilità e probabilmente viola anche 2.4.7 e 2.4.3.

Come Correggere

Strumento di Disegno su Canvas — Non Corretto

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Strumento di Disegno su Canvas — Corretto

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Riordinamento Lista Drag-and-Drop — Non Corretto

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Riordinamento Lista Drag-and-Drop — Corretto

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Controlli di Mappa Interattiva — Non Corretto

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Controlli di Mappa Interattiva — Corretto

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Errori Comuni

• Dare per scontato che l’eccezione dipendente dal percorso di WCAG 2.1.1 sia ancora applicabile: Sviluppatori che conoscono il Livello A talvolta costruiscono strumenti di disegno a mano libera o basati su gesture senza alternative da tastiera, non rendendosi conto che 2.1.3 rimuove esplicitamente questa eccezione. Ogni funzione, incluse quelle sensibili al percorso, deve avere un equivalente da tastiera a questo livello.
• Associare solo gestori onclick e onmousedown a elementi interattivi personalizzati: Widget personalizzati costruiti con elementi <div> o <span> che ascoltano solo eventi di mouse sono completamente irraggiungibili da tastiera. Aggiungi sempre gestori onkeydown o onkeyup insieme ai listener di eventi di mouse e assicurati che l’elemento abbia tabindex='0' e un ruolo ARIA appropriato.
• Usare tabindex='-1' su elementi che dovrebbero essere nell’ordine di tabulazione: Impostare tabindex='-1' rimuove un elemento dall’ordine di tabulazione sequenziale. Questo è appropriato solo per elementi gestiti in modo programmatico (ad esempio, all’interno di un widget composito che usa il roving tabindex). Applicarlo a controlli interattivi autonomi li rende inaccessibili da tastiera.
• Implementare drag-and-drop senza un meccanismo di riordino basato su tastiera: Librerie come SortableJS o implementazioni drag personalizzate spesso non forniscono un’alternativa da tastiera pronta all’uso. Gli sviluppatori devono implementare il pattern ARIA drag-and-drop o fornire un riordino con tasti Freccia Su/Giù in modo che il riordino delle liste sia completamente operabile da tastiera.
• Affidarsi al CSS :hover per mostrare controlli interattivi: Sottomenu a discesa, pulsanti di azione basati su tooltip o controlli che compaiono solo al passaggio del mouse sono inaccessibili alle persone che usano la tastiera, a meno che non siano gestiti anche gli stati :focus e :focus-within. Un utente da tastiera non può mai effettuare hover, quindi i contenuti disponibili solo in hover sono di fatto nascosti.
• Non gestire il focus dopo cambiamenti dinamici del contenuto: Quando si apre una modale, appare un avviso inline o un widget caricato via AJAX sostituisce contenuti esistenti, il focus deve essere spostato in modo programmatico sul nuovo contenuto usando element.focus(). Non farlo lascia le persone che usano la tastiera bloccate nella posizione in cui hanno attivato il cambiamento, senza consapevolezza dell’esistenza del nuovo contenuto.
• Costruire slider personalizzati solo con onmousemove: Slider di tipo range costruiti con elementi <div> che tracciano la posizione del mouse per i cambi di valore devono anche implementare la gestione dei tasti ArrowLeft, ArrowRight, Home e End secondo il pattern ARIA per gli slider, ed esporre il valore corrente tramite aria-valuenow, aria-valuemin e aria-valuemax.
• Posizionare il focus da tastiera dentro iframe senza fornire una via d’uscita: Iframe incorporati—soprattutto quelli che contengono widget di terze parti come mappe, form di pagamento o strumenti di chat—possono intrappolare il focus da tastiera se il contenuto incorporato non è esso stesso accessibile da tastiera e non supporta il tasto Esc per restituire il focus al documento padre.
• Omettere il supporto da tastiera per visualizzazioni dati basate su canvas: Grafici e diagrammi renderizzati su <canvas> sono invisibili alla tastiera e agli screen reader, a meno che non venga fornita un’alternativa accessibile (una tabella dati, un equivalente SVG con ARIA o punti dati navigabili da tastiera) insieme all’elemento canvas.
• Testare l’accessibilità da tastiera solo con Tab e Invio, ignorando i pattern di tasti per i widget compositi: Molti pattern di widget ARIA—menu, alberi, griglie, tabpanel, listbox—richiedono la navigazione con i tasti Freccia all’interno del widget, con un solo punto di tabulazione per l’intero componente (roving tabindex). Testare solo Tab e Invio non rivelerà i fallimenti in questi pattern compositi e darà una falsa sensazione di conformità.

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 un quadro completo di accessibilità web e mobile per un’ampia gamma di enti pubblici e privati che operano in Turchia. La circolare impone la conformità a standard allineati a WCAG 2.1 e 2.2, richiedendo alle organizzazioni interessate di garantire che i propri servizi digitali siano percepibili, operabili, comprensibili e robusti per tutte le persone, incluse quelle con disabilità.

Gli enti coperti da questa regolamentazione includono istituzioni e agenzie pubbliche a tutti i livelli di governo, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e istituzioni sanitarie, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, aziende di trasporto privato e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE). Per queste organizzazioni, la conformità ai criteri di successo di Livello A e Livello AA rappresenta la soglia legale minima.

WCAG 2.1.3 — Tastiera (Senza Eccezioni) è un criterio di Livello AAA e pertanto non è esplicitamente richiesto come requisito legale di base dalla circolare. Tuttavia, lo spirito della regolamentazione—garantire un accesso digitale equo per i milioni di persone con disabilità in Turchia—è fortemente allineato con l’intento di questo criterio. Le organizzazioni nei settori coperti che offrono servizi specializzati a persone con disabilità motorie, o che gestiscono portali governativi utilizzati da cittadini che dipendono da tecnologie assistive, sono fortemente incoraggiate a perseguire la conformità AAA per l’accesso da tastiera.

Raggiungere la conformità a WCAG 2.1.3 segnala un impegno per l’accessibilità di livello eccellente che va oltre i minimi normativi. Per le organizzazioni turche che mirano a servire la più ampia base di utenti possibile, a dimostrare responsabilità sociale o a partecipare ai mercati digitali dell’Unione Europea dove possono applicarsi standard di accessibilità più elevati, implementare una piena operabilità da tastiera senza eccezioni rappresenta sia un vantaggio competitivo sia etico. Man mano che il quadro normativo della Turchia evolve e i meccanismi di applicazione si consolidano, i primi adottanti di criteri di livello AAA come il 2.1.3 saranno in una posizione favorevole per soddisfare eventuali futuri irrigidimenti normativi senza costosi interventi di remediation.