Accessibilità da tastiera in WordPress: il test e le 7 correzioni

Un sito si prova con la tastiera in dieci minuti, e quei dieci minuti trovano più barriere reali di qualunque scansione automatica. Basta staccare il mouse e premere Tab: se non riesci ad aprire il menu, chiudere il banner dei cookie o inviare il modulo di contatto, quel sito è inutilizzabile per una parte dei suoi visitatori, e nessun punteggio te lo aveva detto.

Questa guida è il test da tastiera per intero: chi ne ha bisogno, quali criteri WCAG lo riguardano — inclusi quelli aggiunti dalle 2.2, che nascono proprio da qui — come si esegue il giro passo per passo, quali strumenti aiutano e come si corregge ciascuno dei sette problemi che ricorrono sui siti WordPress.

La tastiera è un blocco di un quadro più ampio: se stai facendo una verifica completa, l’audit di accessibilità di un sito WordPress raccoglie tutti i controlli e i relativi obblighi normativi. Qui si scende in profondità su uno solo.

Chi naviga con la tastiera, davvero

L’idea diffusa è che riguardi «chi non può usare il mouse», e questo fa sembrare il problema più piccolo di quanto sia. Le persone che percorrono un sito senza puntatore sono almeno cinque gruppi diversi:

• Chi usa uno screen reader. Anche chi ha piena mobilità: senza vedere lo schermo il puntatore non serve a niente, e tutta l’interazione passa dalla tastiera. È il gruppo più numeroso, ed è quello che viene dimenticato più spesso perché «vedo che il sito funziona col mouse».
• Chi ha una disabilità motoria permanente o temporanea: tremori, ridotta precisione, uso di una sola mano.
• Chi usa dispositivi alternativi — switch, tastiere a scansione, comandi vocali, puntatori a testa. Quasi tutti si presentano al browser come una tastiera: se il sito funziona da tastiera, funziona con loro.
• Chi è temporaneamente impedito: un braccio ingessato, un mouse scarico, un trackpad che non risponde.
• Chi va di fretta. Utenti esperti che compilano i moduli con Tab perché è più veloce — e che abbandonano un checkout dove la tabulazione salta a caso.

C’è poi una ragione che non riguarda le persone: un sito navigabile da tastiera è un sito con markup semantico corretto, e il markup semantico è quello che i crawler leggono meglio. Non è che l’accessibilità «migliora la SEO» per magia: le due cose hanno la stessa causa a monte, ed è il motivo per cui gerarchia dei titoli e testo dei link compaiono sia qui sia fra i controlli SEO on-page.

I criteri WCAG che riguardano la tastiera

Le WCAG sono lo standard tecnico a cui rimandano le normative europee e italiane. Il riferimento richiesto oggi in Italia è la versione 2.1 livello AA, ma la versione corrente pubblicata dal W3C è la 2.2, Raccomandazione dall’ottobre 2023, e conviene lavorare su quella: è un sovrainsieme della 2.1, e tre dei nove criteri che ha aggiunto nascono esattamente dai problemi di questa guida.

(Una versione precedente di questo articolo indicava le WCAG 2.1 come «le linee guida ufficiali» senza menzionare la 2.2: lo correggo qui invece di aggiornare la cifra in silenzio, perché i criteri aggiunti cambiano cosa va verificato.)

Dalle WCAG 2.0 e 2.1

• 2.1.1 Keyboard (A) — tutte le funzionalità devono essere utilizzabili da tastiera. È il criterio madre.
• 2.1.2 No Keyboard Trap (A) — il focus deve poter uscire da qualunque componente in cui è entrato, usando solo la tastiera.
• 2.1.4 Character Key Shortcuts (A) — se il sito ha scorciatoie a carattere singolo (premere S per cercare), devono poter essere disattivate o rimappate. Riguarda chi usa il comando vocale, che pronuncia lettere per sbaglio, e viene ignorato quasi sempre.
• 2.4.3 Focus Order (A) — l’ordine di tabulazione deve seguire un percorso logico e coerente con il significato del contenuto.
• 2.4.7 Focus Visible (AA) — l’elemento che ha il focus deve essere visibile.

Aggiunti dalle WCAG 2.2

• 2.4.11 Focus Not Obscured (Minimum) (AA) — l’elemento a fuoco non deve essere completamente nascosto da contenuto creato dall’autore. È il criterio degli header appiccicati in alto, ed è quello che fa fallire più temi WordPress moderni.
• 2.4.13 Focus Appearance (AAA) — stabilisce quanto deve essere evidente l’indicatore di focus: area minima e contrasto rispetto allo stato non a fuoco. È AAA, quindi non obbligatorio, ma dice bene cosa distingue un focus «tecnicamente presente» da uno che si vede davvero.
• 3.3.8 Accessible Authentication (Minimum) (AA) — nessun passaggio di autenticazione deve richiedere un test cognitivo (trascrivere caratteri, risolvere un puzzle, ricordare a memoria) senza un’alternativa. È il criterio che mette fuori gioco i CAPTCHA visivi: se ti serve protezione anti-bot, fra le opzioni di hardening del login conviene scegliere quelle che non chiedono all’utente di risolvere un test. Un limite ai tentativi, per esempio, lavora senza chiedere niente a nessuno.

Due criteri della 2.2 riguardano il puntatore e non la tastiera, ma vale la pena conoscerli perché nascono dagli stessi componenti costruiti male: 2.5.7 Dragging Movements (AA), che chiede un’alternativa al trascinamento — è il criterio degli slider —, e 2.5.8 Target Size (Minimum) (AA), che fissa a 24×24 pixel CSS l’area minima di un bersaglio.

Il test manuale, passo per passo

Prima di partire, tre accorgimenti che cambiano il risultato del test:

• Stacca il mouse, o almeno allontanalo. Non è teatro: finché ce l’hai sotto la mano lo usi senza accorgertene e il test non vale.
• Apri il sito in una finestra anonima. Da amministratore vedi la barra di WordPress, un ordine di tabulazione diverso e a volte componenti che i visitatori non hanno.
• Prova su Chrome e su Firefox. Su macOS c’è un dettaglio che confonde: per impostazione predefinita Tab in Safari e in alcune configurazioni di sistema non si ferma su link e pulsanti. Se ti sembra che metà pagina non sia raggiungibile, controlla prima Impostazioni di sistema > Tastiera > Spostamento dello stato attivo con Tab: rischi di segnalare come bug del sito una preferenza del tuo computer.

I tasti che servono

La distinzione fra Tab e frecce è quella che quasi tutti sbagliano quando costruiscono un componente: Tab serve a passare da un componente all’altro, le frecce a muoversi dentro uno. Un gruppo di cinque tab che richiede cinque pressioni di Tab è costruito male, anche se funziona.

Il giro completo

1. Ricarica la pagina e premi Tab una volta sola. La prima cosa che riceve il focus dovrebbe essere un link «Vai al contenuto». Se non c’è, annotalo: è il primo problema.
2. Continua a tabulare fino in fondo alla pagina, guardando solo dove si trova il focus. Se lo perdi di vista anche per un solo elemento, quello è un problema.
3. Torna indietro con Shift+Tab: il percorso deve essere lo stesso al contrario.
4. Scorri la pagina a metà e continua a tabulare. L’elemento a fuoco finisce sotto l’header fisso o sotto il banner dei cookie?
5. Apri ogni componente sovrapposto — menu mobile, modale, popup newsletter, banner cookie, lightbox — e verifica tre cose: che il focus entri dentro, che tabulando resti dentro, che Esc lo chiuda riportando il focus dove eri.
6. Attiva tutto quello che incontri con Invio e con Spazio.
7. Compila e invia un modulo senza toccare il mouse, sbagliando un campo di proposito: l’errore ti raggiunge? Ti dice cosa correggere?
8. Ripeti il giro su ogni tipo di pagina: home, articolo, archivio, ricerca, contatti. E sul carrello e sul checkout, se ci sono.

Annota man mano, non alla fine. Le categorie in cui ricadrà quasi tutto sono quattro: non raggiungibile, raggiungibile ma non attivabile, focus invisibile o coperto, ordine incoerente.

Gli strumenti — e cosa non fanno

Nessuno degli strumenti qui sotto esegue il test al posto tuo: la tastiera è la parte dell’accessibilità che l’analisi automatica copre peggio, perché quasi tutte le domande sono di merito («questo ordine ha senso?») e non di forma. Servono a rendere più veloce il giro manuale, non a sostituirlo.

• Accessibility Insights for Web (Microsoft, gratuito, Chrome ed Edge) — è il più utile dei quattro per questo test. La modalità Tab stops disegna sulla pagina il percorso del focus con numeri progressivi: gli ordini incoerenti si vedono a colpo d’occhio, senza doverli ricostruire a memoria.
• axe DevTools — trova quello che è misurabile sul codice: tabindex positivi, pulsanti senza nome accessibile, ruoli ARIA incoerenti. Non ti dirà mai che l’ordine di tabulazione è illogico.
• Lighthouse (in Chrome DevTools) — utile come panoramica. Attenzione a non leggere il punteggio come un esito: misura ciò che è misurabile in automatico, e un sito impossibile da usare con la tastiera può stare a 100.
• NVDA (Windows, gratuito) e VoiceOver (già installato su macOS, ⌘ + F5) — non sono strumenti di test da tastiera, sono il motivo per cui lo fai. Venti minuti con lo schermo spento dicono quali dei problemi che hai annotato contano davvero.

I sette problemi ricorrenti, e come si correggono

Su un sito WordPress i risultati del test si concentrano quasi sempre in questi sette casi. Per ciascuno: come si riconosce, perché succede e come si corregge.

1. Il focus non si vede

Come si riconosce: tabuli e non succede niente a schermo, ma premendo Invio la pagina cambia. Il focus c’è, semplicemente non è disegnato.

Perché succede: in un punto del CSS del tema c’è un outline: none o un outline: 0, spesso dentro una regola generica applicata a tutti gli elementi. Viene messo perché l’anello del browser compariva anche al click del mouse, e sembrava un difetto grafico.

Come si corregge: con :focus-visible, che è la risposta a quel problema estetico. Il browser applica lo stile solo quando ritiene che l’indicatore serva davvero — cioè quando l’utente sta navigando da tastiera — e lo omette al click del mouse.

/* Toglie l'anello solo a chi ha già :focus-visible, evitando doppioni */
:focus:not(:focus-visible) {
  outline: none;
}

:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 3px;
  border-radius: 2px;
}

Correzione dichiarata: una versione precedente di questo articolo suggeriva lo stesso stile su :focus nudo. Funziona, ma mostra l’anello anche al click del mouse — cioè riproduce esattamente il motivo per cui i temi lo tolgono.

Due dettagli che rendono la correzione efficace invece che formale: il colore dell’outline deve avere almeno 3:1 di contrasto con lo sfondo su cui appare — un anello azzurro chiaro su fondo bianco soddisfa il criterio solo sulla carta — e va provato su tutti i fondi del sito, perché l’header scuro e il corpo chiaro non possono avere lo stesso anello.

2. Il focus finisce sotto l’header fisso

Come si riconosce: tabuli a metà pagina e l’elemento a fuoco sparisce dietro la barra in alto. È il passaggio 4 del giro, ed è il problema che più spesso passa inosservato perché in cima alla pagina non si manifesta.

Perché succede: il browser porta in vista l’elemento a fuoco allineandolo al bordo della finestra, e un header in position: sticky occupa proprio quella fascia — e con lui qualunque altro elemento appiccicato in cima, a partire da una barra che non copre il focus solo se è costruita apposta. Viola il criterio 2.4.11 delle WCAG 2.2.

Come si corregge: si dichiara al browser quanto spazio è occupato in cima, con scroll-padding-top sull’elemento radice. Una riga, e vale anche per i link con àncora.

:root {
  /* stessa altezza dell'header sticky, meglio se è già una variabile del tema */
  scroll-padding-top: 5rem;
}

Se in fondo c’è anche una barra dei cookie o una CTA appiccicata, serve pure scroll-padding-bottom. E se il banner dei cookie copre stabilmente parte della pagina, la soluzione giusta non è il padding: è farlo chiudere.

3. L’ordine di tabulazione non ha senso

Come si riconosce: il focus salta dal menu al footer e poi torna in mezzo alla pagina. Con Tab stops di Accessibility Insights si vede come una linea spezzata.

Perché succede: due cause, e conviene distinguerle. La prima sono i tabindex positivi (tabindex="2" e simili), che forzano un ordine arbitrario e mandano in coda tutto il resto della pagina: non servono quasi mai. La seconda è più insidiosa: l’ordine di tabulazione segue il codice, non la grafica. Se il CSS sposta visivamente un blocco — con order in flexbox, con il posizionamento in grid, con un float — quello che vedi a destra può essere il primo elemento del codice.

Come si corregge: togli i tabindex positivi e usa solo tabindex="0" (rendi raggiungibile) o tabindex="-1" (raggiungibile solo via script). Per lo scarto fra codice e grafica, la correzione è riordinare il markup: se non è possibile, il riordino visivo va limitato ai casi in cui non cambia la sequenza logica di lettura.

4. Un elemento interattivo non si attiva

Come si riconosce: il focus ci arriva (o non ci arriva affatto), ma Invio e Spazio non fanno niente. Col mouse, invece, funziona.

Perché succede: l’elemento è un <div> o uno <span> con un gestore di click attaccato sopra. Il mouse genera l’evento click, la tastiera no — perché su un elemento non interattivo non c’è niente da attivare.

Come si corregge: sostituendo l’elemento, non aggiungendo codice. Un <button> nativo è raggiungibile con Tab, si attiva con Invio e con Spazio, viene annunciato come pulsante dalle tecnologie assistive e supporta lo stato disabilitato — tutto senza una riga di JavaScript.

<!-- No -->
<div class="btn" onclick="eseguiAzione()">Invia</div>

<!-- Sì: nessun gestore da tastiera da scrivere -->
<button type="button" class="btn">Invia</button>

Correzione dichiarata: una versione precedente di questo articolo diceva la cosa giusta nel testo — «usa sempre <button>» — e poi mostrava un gestore keydown per Invio e Spazio. Le due indicazioni sono incompatibili: su un <button> vero quel gestore provoca una doppia attivazione, perché il browser genera già l’evento click alla pressione di quei tasti. Il modulo verrebbe inviato due volte.

Il gestore da tastiera serve solo nel caso in cui l’elemento nativo davvero non sia utilizzabile — accade di rado, e quasi sempre dentro componenti di terze parti che non puoi modificare. In quel caso non basta comunque l’ascoltatore: servono anche role="button", tabindex="0" e un nome accessibile, altrimenti l’elemento resta irraggiungibile o viene annunciato come testo qualsiasi.

5. Il focus resta intrappolato

Come si riconosce: entri in un componente e non ne esci più tabulando. È la barriera peggiore possibile — l’utente deve ricaricare la pagina — e viola il criterio 2.1.2.

Perché succede: di solito è un <iframe> di terze parti (un player video, una mappa, un widget di chat) o una modale scritta a mano che intercetta Tab senza gestire l’uscita.

Come si corregge: qui va fatta una distinzione che confonde spesso. Dentro una modale aperta il focus deve restare confinato: è il comportamento corretto, non una trappola, perché il resto della pagina è inerte. La trappola è un’altra cosa: è quando non c’è modo di chiudere e uscire. Una modale fatta bene apre spostando il focus al suo interno, lo trattiene finché è aperta, si chiude con Esc e restituisce il focus all’elemento che l’aveva aperta — l’ultimo passaggio è quello che manca più spesso, e lascia l’utente all’inizio della pagina dopo ogni chiusura.

Sul markup servono role="dialog", aria-modal="true" e un nome accessibile. Se la modale arriva da un plugin, la strada più veloce è cercare l’opzione nelle sue impostazioni e, se non c’è, cambiarlo.

6. Il menu si apre solo passandoci sopra

Come si riconosce: tabulando arrivi alla voce di menu principale e le sottovoci non compaiono mai. Col mouse si aprono al passaggio.

Perché succede: il sottomenu è mostrato da una regola :hover e basta. È il problema più diffuso in assoluto sui temi WordPress, e rende irraggiungibile una parte intera della navigazione — spesso la più importante.

Come si corregge: se il menu è di solo CSS, la correzione minima è aggiungere :focus-within accanto a :hover, così il sottomenu compare anche quando il focus entra in uno dei suoi elementi.

.menu-item:hover > .sub-menu,
.menu-item:focus-within > .sub-menu {
  display: block;
}

È una toppa, non la soluzione completa: un menu a discesa fatto come si deve ha un <button> che apre e chiude, con aria-expanded che ne dichiara lo stato, e si chiude con Esc. Se il tema è tuo conviene farlo da subito — il menu si registra e si stampa in header.php, ed è lì che va sistemato una volta per tutte.

7. Slider, carousel e mappe non si comandano

Come si riconosce: il componente si muove solo trascinando, oppure ha frecce che il Tab non raggiunge, oppure ruota da solo e non riesci a fermarlo.

Perché succede: sono componenti costruiti pensando al dito su uno schermo touch. Toccano tre criteri insieme: 2.1.1 se non sono raggiungibili, 2.5.7 se l’unico modo di usarli è il trascinamento, 2.2.2 se si muovono da soli per più di cinque secondi senza un comando di pausa.

Come si corregge: la domanda da farsi prima di mettersi a scrivere codice è se quel carousel serva. Nella maggior parte dei siti WordPress lo slider in home mostra tre messaggi di cui i visitatori vedono solo il primo, pesa parecchio in fase di caricamento ed è il componente che rompe più test di accessibilità: sostituirlo con contenuto statico risolve tutti e tre i problemi in una volta. Se deve restare, i requisiti minimi sono frecce che siano <button> raggiungibili, un comando di pausa visibile e un’alternativa al trascinamento.

Vale lo stesso criterio con cui si valuta un plugin prima di installarlo: se il componente non è mantenuto e non dichiara nulla sull’accessibilità, quelle correzioni non arriveranno mai da sole.

I plugin: quali aiutano e quale ho tolto da questa guida

Nessun plugin rende un sito navigabile da tastiera. Due però tolgono lavoro ripetitivo, e vale la pena distinguerli da una terza categoria che negli ultimi anni si è mescolata alle prime due.

WP Accessibility

WP Accessibility è scritto e mantenuto da Joe Dolson, che fa parte del team Accessibility di WordPress. Non è un plugin «tutto in uno»: è una raccolta di correzioni puntuali che si attivano una per una. Quelle che riguardano questa guida sono lo skip link con destinazione configurabile, il ripristino dell’outline del focus nei temi che lo disattivano, la rimozione dei tabindex non necessari e l’aggiunta del titolo dell’articolo ai link «Leggi tutto» — che se il tema è tuo si sistema direttamente nel template di archivio.

La cosa che lo qualifica più di ogni elenco di funzioni è quello che dichiara di sé: non è pensato per rendere il sito conforme ad alcuna linea guida di accessibilità. È esattamente la frase che un fornitore serio scrive e che un venditore di conformità automatica non scriverebbe mai.

Le sue correzioni restano comunque toppe applicate sopra il tema: se il tema è tuo, gli stessi risultati si ottengono meglio nel codice, e il plugin resta la scelta giusta quando il tema è di terze parti e non vuoi modificarlo.

Accessibility Checker (Equalize Digital)

Analizza ogni articolo e pagina dentro l’editor, al momento del salvataggio, e segnala le violazioni sul contenuto appena scritto: link senza testo comprensibile, pulsanti senza nome accessibile, immagini senza alternativa testuale. È utile soprattutto a chi pubblica, perché sposta il controllo nel momento in cui costa meno correggere.

Il plugin è Accessibility Checker sulla directory ufficiale. Lo preciso perché il nome è molto generico e circolano prodotti diversi con la stessa etichetta: una versione precedente di questo articolo lo attribuiva correttamente a Equalize Digital ma rimandava al sito di un’altra azienda, che vende una piattaforma SaaS senza rapporto con il plugin.

Il plugin che ho tolto, e perché

Fino a questa revisione la guida consigliava One Click Accessibility come «soluzione plug & play» per skip link, contrasto elevato e outline del focus. Va tolto per tre ragioni che si sono accumulate nel tempo, e preferisco dichiararlo invece di far sparire il paragrafo.

Il collegamento non funzionava più. Il link che l’articolo conteneva risponde con un errore del server: era rotto, e su una pagina online da oltre un anno nessuno se n’era accorto.

Quel plugin non esiste più con quel nome. È stato acquisito, rinominato una prima volta in Ally e poi di nuovo, ed è oggi mantenuto da Elementor. Un lettore che cercasse «One Click Accessibility» non troverebbe la cosa descritta qui.

Soprattutto: nel frattempo è diventato un’altra cosa. Alla raccolta di correzioni puntuali si è aggiunto un widget di accessibilità — il pannellino flottante che offre al visitatore di ingrandire il testo, aumentare il contrasto, fermare le animazioni. È la categoria di strumenti che agisce a valle sulla pagina già costruita, e che per costruzione non può correggere né la struttura né il markup né i contenuti: perché un overlay non chiude un audit di accessibilità è spiegato per esteso nel pillar, insieme al caso su cui la Federal Trade Commission è intervenuta nel gennaio 2025.

Nessuno dei problemi elencati in questa guida si risolve con un widget. Il focus invisibile, il menu che si apre solo in hover, il <div> usato come pulsante: sono tutte cose che stanno nel markup e nel CSS, e lì vanno corrette.

Se il tema lo scrivi tu, non si pone

Quasi tutto quello che sta in questa guida è la correzione di una scelta fatta male da qualcun altro. Se il tema lo sviluppi tu, le stesse cose si mettono in piedi all’inizio e costano poche righe: lo skip link come primo elemento del <body>, i landmark <header>, <nav>, <main> e <footer> al posto dei <div>, :focus-visible definito una volta nel foglio di stile, scroll-padding-top se l’header è fisso.

Sono decisioni che vanno prese al momento dei primi file, non aggiunte dopo: creare un tema WordPress da zero le colloca dove si prendono davvero. E se il tema è destinato a un cliente o alla distribuzione, l’accessibilità è una riga della checklist prima del rilascio — verificarla lì costa molto meno che scoprirla in produzione.

Se invece il tema lo stai scegliendo, il filtro accessibility-ready della directory ufficiale è il punto di partenza — con l’avvertenza che certifica il tema e non il tuo sito. È uno dei criteri che entrano nella scelta di un tema WordPress professionale, e vale la pena provare i sette casi qui sopra sulla demo prima di adottarlo: dieci minuti, e ti risparmiano il lavoro di questa guida.

Le regole che evitano di rifare tutto

• Usa l’elemento nativo. <button> per le azioni, <a> per la navigazione, <label> collegata a ogni campo. Il novanta per cento dei problemi di tastiera nasce dall’aver sostituito uno di questi con un <div>.
• La prima regola di ARIA è non usare ARIA. Un role="button" su un <div> è sempre peggio di un <button>: dichiara un comportamento che poi devi implementare a mano, e se lo implementi male l’utente sta peggio di prima.
• Niente tabindex positivi. Solo 0 e -1.
• Ogni cosa che risponde a :hover deve rispondere anche a :focus-visible. Cercare :hover nel CSS del tema e controllare una per una le regole trovate è mezz’ora ben spesa.
• Prova i componenti mentre li scrivi, non alla fine. Un componente nuovo si collauda con Tab, Invio, Spazio ed Esc in trenta secondi.
• Rifai il giro dopo ogni cambio di tema o di plugin del frontend. È il momento in cui i problemi tornano.

Domande frequenti

Da qui in avanti

Se hai completato il giro e hai una lista di punti in cui ti sei bloccato, hai già fatto la parte che conta. L’ordine con cui correggerli è quello dei sette casi qui sopra: il focus invisibile e il menu in hover sbloccano da soli la maggior parte della navigazione, e si sistemano nel CSS del tema.

Il passo successivo è allargare la verifica al resto: contrasto, testi alternativi, moduli, documenti allegati e gli obblighi normativi che dal 2025 riguardano anche i siti privati. Sono i ventiquattro punti della checklist di audit dell’accessibilità WordPress, di cui quello che hai appena fatto è il blocco D.

Se preferisci che il giro lo faccia io sul tuo sito — test da tastiera e con screen reader sul campione di pagine, correzione di quello che non passa direttamente nel tema, e il documento con gli esiti — scrivimi e ne parliamo.