WCAG 2.1.4: Scorciatoie da tastiera basate sui caratteri

Cosa significa questa regola

WCAG 2.1.4 — Scorciatoie da tastiera con tasti carattere è un criterio di successo di Livello A introdotto in WCAG 2.1. Affronta un pericolo di accessibilità specifico ma serio: quando un’applicazione web assegna scorciatoie da tastiera costituite da un singolo carattere stampabile — una lettera, un numero, un segno di punteggiatura o un simbolo — senza richiedere un tasto modificatore come Ctrl, Alt, Meta o Shift insieme ad esso.

Il criterio stabilisce che, se una scorciatoia da tastiera è implementata nei contenuti usando solo un singolo tasto carattere, almeno una delle seguenti condizioni deve essere vera:

• Disattivazione: È disponibile un meccanismo che consente all’utente di disattivare completamente la scorciatoia.
• Rimappatura: È disponibile un meccanismo che consente all’utente di rimappare la scorciatoia in modo che utilizzi uno o più tasti modificatori non stampabili (come Ctrl o Alt).
• Attiva solo con focus: La scorciatoia da tastiera per un componente dell’interfaccia utente è attiva solo quando quel componente ha il focus.

Una scorciatoia con singolo tasto carattere è una scorciatoia attivata premendo un singolo tasto che produce un carattere stampabile — per esempio, premere G per aprire una galleria, premere / per portare il focus sulla barra di ricerca o premere N per comporre un nuovo messaggio. Queste differiscono in modo fondamentale da scorciatoie come Ctrl+S o Alt+F4, che richiedono un modificatore non stampabile e sono quindi al di fuori dell’ambito di questo criterio.

Una scorciatoia rispetta questo criterio se l’applicazione: (1) fornisce una pagina di impostazioni o preferenze in cui le scorciatoie a tasto singolo possono essere disabilitate o modificate in combinazioni multi-tasto; (2) rimappa automaticamente a scorciatoie basate su modificatori; oppure (3) attiva la scorciatoia solo quando l’elemento che la innesca ha il focus da tastiera — il che significa che premere il tasto mentre il focus è altrove non produce alcun effetto.

Una scorciatoia non rispetta il criterio se una pressione di tasto a singolo carattere attiva un’azione globale in qualsiasi momento, indipendentemente da quale elemento abbia il focus, e non esiste alcun modo per l’utente di disattivarla o modificarla. Un esempio reale comune è una single-page application che attiva un’azione di navigazione ogni volta che l’utente preme un tasto lettera, anche mentre sta compilando un campo di testo o dettando del testo.

Il criterio include una eccezione ufficiale importante: non si applica quando la scorciatoia è attiva solo mentre un componente specifico ha il focus. Per esempio, un widget di menu a discesa personalizzato che ascolta i tasti lettera solo quando il menu a discesa stesso è aperto e ha il focus è accettabile, perché il contenimento del focus limita il rischio di attivazioni accidentali.

Perché è importante

Questo criterio esiste principalmente per proteggere due gruppi di utenti, anche se i suoi benefici si estendono oltre.

Gli utenti che usano input vocale sono i più direttamente interessati. Le persone con disabilità motorie spesso controllano completamente il computer tramite software di riconoscimento vocale come Dragon NaturallySpeaking (ora Dragon Professional). Durante la dettatura di testo o l’emissione di comandi vocali, questi strumenti generano pressioni di tasti che possono inavvertitamente attivare scorciatoie a singolo carattere sulla pagina web attiva. Immagina un utente che detta un modulo medico e dice “next” — se l’applicazione ascolta globalmente la lettera N, potrebbe navigare via dal modulo, distruggendo il lavoro dell’utente. Secondo il CDC, circa 61 milioni di adulti negli Stati Uniti vivono con una disabilità, e una parte significativa fa affidamento su metodi di input alternativi, incluso il riconoscimento vocale.

Gli utenti con disabilità motorie che usano accesso a scansione, dispositivi a soffio e aspirazione o navigazione solo da tastiera sono anch’essi a rischio. Questi utenti possono premere tasti inavvertitamente o scorrere su più tasti mentre cercano di raggiungere un obiettivo. Una singola pressione errata che attiva un’azione irreversibile — come archiviare un’email, eliminare un file o inviare un modulo — può causare notevole frustrazione e perdita di dati.

Gli utenti con disabilità cognitive possono essere anch’essi danneggiati. Utenti con disturbi dell’attenzione o utenti che non conoscono l’interfaccia possono premere tasti in modo sperimentale per esplorare la pagina, ignari del fatto che le scorciatoie a singolo carattere sono attive. Navigazioni o cambi di stato inattesi aumentano il carico cognitivo e la disorientazione.

Considera questo scenario reale: una piattaforma di e-commerce turca implementa scorciatoie a tasto singolo per utenti esperti — premere C per andare al carrello, premere F per andare ai preferiti. Un utente che usa input vocale cerca di dettare il proprio indirizzo di spedizione in un campo del modulo. Quando dice “Caddesi” (la parola turca per “via”), il software di riconoscimento vocale emette la lettera C prima che il focus entri completamente nell’input, attivando la navigazione alla pagina del carrello. L’indirizzo inserito parzialmente viene perso. L’utente deve ricominciare da capo e, se l’esperienza si ripete, potrebbe abbandonare il sito del tutto.

Oltre all’accessibilità, risolvere i problemi relativi a questo criterio migliora l’usabilità complessiva. Fornire un’interfaccia di personalizzazione delle scorciatoie segnala un prodotto maturo, che rispetta l’utente. Può anche ridurre le richieste di supporto da parte di utenti frustrati che attivano scorciatoie accidentalmente.

Regole Axe-core correlate

WCAG 2.1.4 richiede test manuali perché gli strumenti automatici non possono rilevare in modo affidabile tutte le scorciatoie da tastiera a singolo carattere o verificare se esiste un meccanismo di rimappatura/disattivazione. Ecco perché l’automazione non è sufficiente e cosa devono cercare manualmente i tester:

• Nessuna regola axe-core dedicata (controllo manuale richiesto): Axe-core e Lighthouse non hanno una regola automatizzata che segnali specificamente le scorciatoie da tastiera a singolo carattere. Il motivo è architetturale: il comportamento delle scorciatoie da tastiera è implementato nei listener di eventi JavaScript (keydown, keyup, keypress), e l’analisi statica del DOM non può determinare quale azione attiverà una determinata pressione di tasto, se tale azione è globale o limitata al focus, o se esiste un meccanismo di disattivazione/rimappatura esposto all’utente. Uno strumento dovrebbe simulare pressioni di tasti per tutti i possibili caratteri e osservare i cambiamenti di stato dell’applicazione risultanti — un compito combinatoriamente costoso e dipendente dal contesto che supera le attuali capacità di test automatizzati.
• Ispezione dei listener di eventi (automazione parziale): Gli Strumenti di sviluppo del browser possono elencare i listener di eventi associati agli elementi document, window o body. Se un sito associa un listener keydown a document e l’ispezione del suo sorgente rivela logica di confronto con singoli caratteri, questo è un forte segnale che richiede verifica manuale. Tuttavia, lo strumento non può determinare da solo se il comportamento risultante costituisce una scorciatoia o se è presente un meccanismo di disattivazione.
• Librerie di scorciatoie specifiche del framework: Molte applicazioni React, Vue o Angular usano librerie come react-hotkeys-hook, tinykeys o Mousetrap che registrano scorciatoie globali. Un audit manuale dovrebbe verificare la presenza di queste dipendenze nel sorgente della pagina o nel pannello di rete, quindi testare ogni scorciatoia registrata rispetto ai requisiti del criterio.

Come testare

1. Esaminare l’applicazione per scorciatoie note a singolo carattere: Leggi la documentazione disponibile, le pagine di aiuto o le finestre di riferimento delle scorciatoie da tastiera (spesso aperte con ? o accessibili tramite un menu Aiuto). Elenca tutte le scorciatoie documentate che usano un singolo carattere senza tasto modificatore.
2. Ispezionare i listener di eventi JavaScript: Apri Chrome DevTools o Firefox DevTools, vai al pannello Elements o Sources e usa la scheda Event Listeners per ispezionare i listener su document, window e body. Cerca gestori keydown, keyup o keypress. Espandi e leggi il sorgente del gestore per vedere se vengono testati tasti a singolo carattere senza controlli sui modificatori (cioè il codice controlla event.key === 'n' senza controllare anche event.ctrlKey || event.metaKey || event.altKey).
3. Testare le scorciatoie da tastiera mentre il focus è in un input di testo: Fai clic in un campo di testo, una casella di ricerca o una textarea. Poi premi ciascuna scorciatoia a singolo carattere che hai identificato. Se la scorciatoia si attiva (avviene una navigazione, viene attivata un’azione, cambia lo stato), si tratta di un errore — la scorciatoia non è limitata al focus ed è attiva anche quando l’utente sta digitando.
4. Testare con NVDA + Firefox: Abilita la modalità Browse di NVDA (Insert+Space per attivare/disattivare). In modalità Browse, NVDA usa tasti di navigazione a singola lettera (H per le intestazioni, B per i pulsanti, ecc.). Avvia l’applicazione web da testare. Passa alla modalità Focus (Insert+Space) e detta o digita del testo. Verifica che le scorciatoie a singolo carattere della pagina non vadano in conflitto con le pressioni di tasti della modalità Browse di NVDA e che non vengano attivate azioni indesiderate.
5. Testare con JAWS + Chrome: Allo stesso modo, JAWS usa tasti di navigazione rapida a singola lettera. Avvia l’applicazione, naviga tramite il cursore virtuale di JAWS e verifica che le scorciatoie dell’applicazione non si attivino inaspettatamente mentre JAWS elabora le pressioni di tasti.
6. Testare con VoiceOver + Safari (macOS): Abilita VoiceOver (Cmd+F5). Usa VO+Shift+Freccia giù per interagire con le aree di contenuto. Verifica che le scorciatoie con tasti lettera sulla pagina non interferiscano con i comandi di navigazione di VoiceOver.
7. Simulare l’input vocale: Se sono disponibili Dragon NaturallySpeaking o Windows Speech Recognition, detta del testo in un campo di modulo mentre l’applicazione è aperta. Pronuncia parole e frasi comuni che iniziano con lettere usate come scorciatoie. Verifica che non vengano attivate azioni indesiderate.
8. Verificare il meccanismo di disattivazione o rimappatura: Se esistono scorciatoie a singolo carattere, individua l’interfaccia di impostazioni o preferenze che consente di disattivarle o rimapparle. Conferma che sia raggiungibile solo tramite tastiera e che funzioni correttamente. Verifica che, dopo aver disattivato una scorciatoia, premere il carattere non attivi più l’azione.

Come correggere

Scorciatoia globale a singolo carattere senza controllo del modificatore — Errato

<!-- JavaScript associato a document si attiva su qualsiasi pressione del tasto 'n' a livello globale -->
<script>
document.addEventListener('keydown', function(event) {
  if (event.key === 'n') {
    // Naviga alla finestra di composizione nuovo messaggio
    openComposeWindow();
  }
});
</script>

Scorciatoia globale a singolo carattere — Corretto: aggiungere il requisito del modificatore e un interruttore di disattivazione

<!-- Approccio corretto 1: richiedere un tasto modificatore (Ctrl+N) per evitare attivazioni accidentali -->
<script>
document.addEventListener('keydown', function(event) {
  // Attivare solo quando Ctrl o Meta (Cmd su Mac) è anche premuto
  if ((event.ctrlKey || event.metaKey) && event.key === 'n') {
    openComposeWindow();
  }
});
</script>

<!-- Approccio corretto 2: se è necessaria una scorciatoia a singolo carattere, fornire un interruttore di disattivazione -->
<button type='button' id='toggle-shortcuts' aria-pressed='true'>
  Keyboard shortcuts enabled
</button>
<script>
let shortcutsEnabled = true;
document.getElementById('toggle-shortcuts').addEventListener('click', function() {
  shortcutsEnabled = !shortcutsEnabled;
  this.setAttribute('aria-pressed', shortcutsEnabled.toString());
  this.textContent = shortcutsEnabled ? 'Keyboard shortcuts enabled' : 'Keyboard shortcuts disabled';
});

document.addEventListener('keydown', function(event) {
  if (!shortcutsEnabled) return; // Rispettare la preferenza dell'utente
  if (event.key === 'n') {
    openComposeWindow();
  }
});
</script>

Scorciatoia attiva all’interno di un widget con focus — Errato

<!-- La scorciatoia ascolta sull'intero document, non è limitata al widget -->
<div id='autocomplete-list' role='listbox'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
// BUG: associato a document, si attiva anche quando l'autocomplete non ha il focus
document.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Scorciatoia attiva all’interno di un widget con focus — Corretto: limitare il listener al widget

<!-- Corretto: il listener è sull'elemento widget; la scorciatoia si attiva solo quando ha il focus -->
<div id='autocomplete-list' role='listbox' tabindex='0'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
var widget = document.getElementById('autocomplete-list');
// Listener sul widget stesso: Enter si attiva solo quando la listbox ha il focus
widget.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Nessuna interfaccia di rimappatura accessibile all’utente — Errato

<!-- L'applicazione registra scorciatoie con una libreria ma non offre una pagina di impostazioni -->
<!-- L'utente non ha modo di modificare o disattivare 'g' (vai alla galleria) o 'c' (vai al carrello) -->
<script src='hotkeys.min.js'></script>
<script>
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
</script>

Nessuna interfaccia di rimappatura accessibile all’utente — Corretto: aggiungere un pannello di impostazioni accessibile

<!-- Pannello di impostazioni accessibile tramite tastiera; consente all'utente di attivare/disattivare tutte le scorciatoie a singolo carattere -->
<nav aria-label='Accessibility settings'>
  <button type='button' id='open-shortcut-settings'>Keyboard shortcut settings</button>
</nav>

<dialog id='shortcut-settings-dialog' aria-labelledby='dialog-title'>
  <h2 id='dialog-title'>Keyboard Shortcuts</h2>
  <label>
    <input type='checkbox' id='enable-single-char' checked />
    Enable single-character keyboard shortcuts (G, C, N...)
  </label>
  <p>Disable this if you use speech recognition software or experience accidental activations.</p>
  <button type='button' id='close-dialog'>Save and close</button>
</dialog>

<script src='hotkeys.min.js'></script>
<script>
var checkbox = document.getElementById('enable-single-char');

function applyShortcuts() {
  if (checkbox.checked) {
    hotkeys('g', function() { goToGallery(); });
    hotkeys('c', function() { goToCart(); });
  } else {
    hotkeys.unbind('g');
    hotkeys.unbind('c');
  }
}

applyShortcuts();
checkbox.addEventListener('change', applyShortcuts);

document.getElementById('open-shortcut-settings').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').showModal();
});
document.getElementById('close-dialog').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').close();
});
</script>

Errori comuni

• Registrare scorciatoie su document o window senza verificare se un elemento di input ha attualmente il focus: Anche se esiste un meccanismo di disattivazione, molte implementazioni dimenticano di controllare document.activeElement e di sopprimere la scorciatoia quando l’utente si trova all’interno di un elemento <input>, <textarea> o contenteditable, causando interferenze con la digitazione normale.
• Considerare la scorciatoia ? (apri aiuto) come esente: Il punto interrogativo è un carattere stampabile e una scorciatoia a singolo carattere. Non è esente da questo criterio a meno che non sia limitato al focus o esista un meccanismo di disattivazione/rimappatura.
• Disattivare le scorciatoie solo negli input di testo ma non nelle regioni contenteditable o negli editor di testo avanzati: Gli utenti che usano input vocale spesso dettano in elementi contenteditable usati dagli editor di testo avanzati (come quelli nelle piattaforme CMS). Non sopprimere le scorciatoie globali in questi contesti viola comunque il criterio.
• Memorizzare la preferenza dell’utente per le scorciatoie solo nella memoria di sessione: Se l’utente disattiva le scorciatoie e poi aggiorna la pagina, la preferenza dovrebbe essere mantenuta (in localStorage o in un’impostazione del profilo utente) in modo che non debba disattivare le scorciatoie a ogni visita.
• Rendere l’interfaccia delle impostazioni delle scorciatoie stessa inaccessibile: Collocare l’opzione di disattivazione/rimappatura in profondità in un menu non raggiungibile tramite tastiera, o usare un widget di attivazione personalizzato senza un corretto role='switch' e aria-checked, significa che il meccanismo di correzione è inutilizzabile proprio dagli utenti a cui è destinato.
• Dare per scontato che contino solo i tasti lettera: I tasti numerici (1–9), i tasti di punteggiatura (/, ., virgola, punto e virgola) e i tasti simbolo (#, @, !) sono tutti caratteri stampabili. Le scorciatoie a singolo tasto che usano questi caratteri sono ugualmente soggette al criterio.
• Non documentare quali scorciatoie esistono: Anche se è presente un meccanismo di disattivazione, gli utenti non possono usarlo efficacemente se non sanno quali scorciatoie sono attive. È fortemente raccomandato fornire un riferimento visibile e accessibile da tastiera alle scorciatoie (come una finestra di dialogo aperta tramite un pulsante di aiuto).
• Usare una configurazione predefinita di una libreria di scorciatoie che effettua il binding globale senza leggerne la documentazione: Librerie come Mousetrap, Hotkeys.js e tinykeys effettuano il binding all’ambito globale per impostazione predefinita. Gli sviluppatori spesso le usano senza leggere la documentazione sulle restrizioni di ambito o sui requisiti dei modificatori, creando involontariamente violazioni del criterio su larga scala.
• Non testare con il riconoscimento vocale prima del rilascio: I team che non includono Dragon NaturallySpeaking nel proprio toolkit di QA spesso scoprono i conflitti con scorciatoie a singolo carattere solo dopo la messa in produzione, quando gli utenti che usano input vocale segnalano problemi.
• Credere che, poiché la scorciatoia è “opzionale” o “per utenti esperti”, sia esente: Il criterio si applica a tutte le scorciatoie a singolo carattere indipendentemente dal fatto che siano presentate come funzionalità avanzate. L’optionalità della funzionalità non la esenta dal requisito 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 requisiti obbligatori di accessibilità web e mobile allineati a WCAG 2.2. WCAG 2.1.4 — Scorciatoie da tastiera con tasti carattere è un criterio di successo di Livello A, collocandolo nel livello di priorità più alto degli obblighi previsti dalla circolare.

La circolare copre un’ampia gamma di entità che operano in Turchia. Le istituzioni pubbliche — inclusi ministeri, municipalità, università statali, ospedali pubblici e agenzie governative — devono raggiungere la piena conformità al Livello A entro un anno dalla data di pubblicazione della circolare. Le entità del settore privato nelle categorie coperte dispongono di una finestra di conformità di due anni. Le entità private coperte includono piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società 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 (MoNE).

Per queste organizzazioni, non conformarsi a WCAG 2.1.4 non è solo una questione di buone pratiche — è un obbligo legale. Un sito di e-commerce turco che implementa scorciatoie di navigazione dei prodotti a singolo carattere senza un meccanismo di disattivazione, o il portale online di una banca turca che usa scorciatoie con tasti lettera nel proprio flusso di transazioni, sarebbe in violazione diretta dei requisiti della circolare.

In pratica, i team di conformità delle entità coperte dovrebbero esaminare i propri codebase JavaScript e qualsiasi libreria di widget di terze parti alla ricerca di scorciatoie globali a singolo carattere come attività specifica durante i progetti di remediation per il Livello A di WCAG 2.2. Poiché questo criterio richiede test manuali, le scansioni automatiche di accessibilità da sole non evidenzieranno le violazioni — è necessario un passaggio dedicato di test con tastiera e input vocale. Le organizzazioni che usano sistemi di gestione dei contenuti o framework front-end dovrebbero esaminare le implementazioni di scorciatoie a livello di piattaforma (per esempio, le scorciatoie da tastiera predefinite dell’area di amministrazione del CMS esposte sulle pagine rivolte ai clienti) oltre al codice applicativo personalizzato.

L’SDK di overlay di Accsible assiste le entità coperte fornendo un pannello di preferenze di accessibilità accessibile all’utente che può esporre un interruttore di disattivazione delle scorciatoie agli utenti finali, aiutando le organizzazioni a soddisfare il requisito del “meccanismo per disattivare” di WCAG 2.1.4 senza richiedere il refactoring completo del codebase. Ciò è particolarmente prezioso per le organizzazioni che gestiscono applicazioni legacy in cui modificare la logica sottostante delle scorciatoie JavaScript è dispendioso in termini di risorse. Tuttavia, le organizzazioni dovrebbero notare che fare affidamento esclusivamente su un overlay per la conformità non sostituisce la correzione delle implementazioni di scorciatoie sottostanti, e un approccio stratificato che combini strumenti di overlay con remediation a livello di codice sorgente fornisce il percorso più solido verso la conformità ai sensi della circolare presidenziale.