Cookie banner accessibile: focus, consenso e tastiera senza bloccare l’utente

Un cookie banner accessibile non è semplicemente un riquadro con pulsanti grandi e colori leggibili. Deve permettere a chi usa la tastiera o uno screen reader di capire le scelte, esprimerle e continuare a navigare senza ostacoli. Eppure un cookie banner accessibile può essere trascurato anche su un sito che ha già corretto menu, moduli e checkout: basta una finestra che cattura male il focus o un pulsante di rifiuto difficile da raggiungere.

Vediamo come distinguere consenso e WCAG, scegliere il comportamento del banner e verificare una CMP (Consent Management Platform).

In breve. Un banner corretto sul piano privacy non è necessariamente accessibile. Servono comandi raggiungibili da tastiera, nomi e stati comprensibili, focus visibile e gestito in modo coerente, possibilità di proseguire senza accettare i cookie facoltativi e una strada semplice per modificare le preferenze. La verifica automatica è utile, ma non sostituisce una prova pratica.

Cookie banner accessibile: consenso privacy e WCAG sono due verifiche diverse

Le Linee guida sui cookie del Garante Privacy riguardano la validità del consenso e le modalità per esprimere le preferenze. In particolare, il tracciamento non necessario deve restare disattivato prima di un consenso valido; scorrere la pagina o continuare a navigare, da soli, non significano accettare.

Il modello indicato dal Garante permette di chiudere il banner con una X mantenendo le impostazioni predefinite, senza attivare cookie facoltativi. Prevede inoltre l’accesso alle scelte granulari e la possibilità di modificare successivamente le preferenze. Un pulsante esplicito «Rifiuta cookie facoltativi» è una soluzione particolarmente chiara, ma non va confuso con l’obbligo, in ogni configurazione, di usare proprio quella dicitura.

Le WCAG affrontano un’altra domanda: tutte queste operazioni sono effettivamente utilizzabili? Un consenso può essere gestito correttamente nel database, ma il banner può impedire a una persona di selezionare «Rifiuta» con Tab, non comunicare lo stato dei toggle o coprire il pulsante che ha il focus.

Occorre dunque verificare sia i cookie effettivamente installati sia l’interazione.

Un banner corretto sul piano privacy non è necessariamente accessibile.

Banner modale, non modale o persistente: quale modello scegliere?

Le WCAG non impongono di rendere modale ogni cookie banner. Il comportamento deve essere coerente e non impedire la navigazione.

Per una vera finestra modale, il pattern Dialog Modal del W3C richiede di spostare il focus all’interno, contenerlo durante l’interazione e consentire la chiusura con Esc. Attributi come role="dialog", aria-labelledby e aria-modal="true" hanno senso soltanto se il componente si comporta davvero come una modale.

Un banner non modale non deve intrappolare il focus né coprire i controlli della pagina sottostante.

Dove deve andare il focus quando si apre il cookie banner?

Dipende dal modello. Se il banner è modale, il focus deve passare a un elemento al suo interno; non è però obbligatorio collocarlo sul pulsante «Accetta tutti». In presenza di testo articolato può essere più utile focalizzare il titolo del dialogo, reso programmaticamente focalizzabile, così che la persona possa leggere l’informazione prima di scegliere.

Tab e Maiusc+Tab devono attraversare i comandi in una sequenza comprensibile, senza salti inattesi o elementi nascosti raggiungibili da tastiera.

Se le preferenze sono state aperte dal footer, alla chiusura il focus dovrebbe tornare al pulsante d’origine. Alla prima visita va scelta invece una destinazione logica nella pagina.

Attenzione alla focus trap. In una modale corretta il focus resta nel dialogo mentre è aperto: non è un errore. Diventa una trappola quando la persona non può chiudere la finestra, non riesce a completare una scelta o rimane bloccata dopo la sua scomparsa.

In una modale corretta il focus resta nel dialogo mentre è aperto: non è un errore.

Pulsanti, X e toggle: nomi accessibili e stati comprensibili

«Accetta tutti», «Rifiuta cookie facoltativi» e «Personalizza preferenze» sono esempi di etichette che descrivono l’azione. Un’icona X, invece, non dovrebbe essere annunciata soltanto come «pulsante» o «chiudi»: un nome come «Chiudi e continua senza accettare i cookie facoltativi» chiarisce anche l’effetto della scelta iniziale.

I controlli devono essere veri pulsanti HTML o componenti equivalenti con nome, ruolo, stato e comportamento da tastiera corretti. Un elemento grafico cliccabile soltanto con il mouse non basta; nemmeno un aria-label può riparare un controllo che non si attiva con la tastiera.

Per le categorie di consenso, checkbox native sono spesso la scelta più semplice. Se si usa un toggle con role="switch", lo stato deve essere comunicato con aria-checked="true" o false, la barra spaziatrice deve modificarlo e l’etichetta non deve cambiare quando cambia lo stato. Sono le indicazioni del pattern Switch WAI-ARIA.

Le categorie facoltative devono partire disattivate quando è richiesto il consenso preventivo; i cookie necessari possono essere indicati come sempre attivi. Un pulsante «Salva preferenze» chiarisce quando le modifiche diventano effettive.

Il tasto Esc può chiudere il banner senza prestare consenso?

Per una finestra realizzata come dialogo modale, Esc è il comportamento previsto dal pattern WAI-ARIA. Alla prima visita, la chiusura deve lasciare disattivato il tracciamento facoltativo: chiudere non equivale ad accettare. Lo stesso principio vale per la X, secondo il modello indicato dal Garante.

Va distinto il caso in cui la persona riapre le impostazioni dopo avere già salvato una scelta. Qui Esc può annullare le modifiche non confermate e ripristinare le preferenze precedentemente memorizzate; non deve essere interpretato automaticamente come una revoca di un consenso già espresso.

Il consenso deve poter essere modificato o revocato anche in seguito. Un pulsante «Gestisci preferenze cookie» nel footer è una soluzione pratica, purché sia accessibile.

Cookie banner accessibile su mobile: zoom, reflow e focus non coperto

Su smartphone o con zoom al 200%, pulsanti e toggle rischiano di diventare irraggiungibili.

Il criterio WCAG 1.4.10 Reflow richiede, nei casi applicabili, la fruizione dei contenuti a una larghezza equivalente a 320 pixel CSS senza scorrimento in due direzioni. Se la modale contiene molte opzioni, deve poter scorrere internamente senza perdere pulsanti e comandi di chiusura.

C’è poi un problema preciso: la barra sticky che copre il collegamento su cui è arrivato il focus. Le WCAG 2.2 introducono il criterio 2.4.11 Focus Not Obscured (Minimum), livello AA: un componente focalizzato non deve essere interamente nascosto da contenuti creati dall’autore. Il W3C cita espressamente i cookie banner tra gli esempi. Non è un criterio presente nelle WCAG 2.1, ma è già utile adottarlo come controllo progettuale.

Verifica anche che il focus sia visibile, che i testi abbiano contrasto adeguato e che X e toggle abbiano aree di attivazione sufficienti. Per il criterio WCAG 2.2 2.5.8 Target Size (Minimum) il riferimento è 24 × 24 pixel CSS, con le eccezioni previste dallo standard; per comodità d’uso spesso conviene progettare aree più ampie.

Test del cookie banner accessibile: dieci minuti con tastiera e screen reader

Parti da una sessione senza preferenze salvate e prova questo percorso:

1. Apri il sito senza usare il mouse. Controlla se il banner viene annunciato e dove si colloca il focus.
2. Usa Tab e Maiusc+Tab. Tutti i pulsanti e i collegamenti sono raggiungibili in un ordine comprensibile?
3. Attiva «Personalizza» con Invio; usa Spazio sui checkbox o sui toggle. Lo stato cambia ed è annunciato correttamente?
4. Prova X ed Esc. Riesci a proseguire senza accettare cookie facoltativi? Il focus torna in un punto sensato?
5. Riapri le preferenze dal footer. Puoi modificare o revocare una scelta senza ricominciare da capo?
6. Ripeti il test con NVDA e un browser compatibile, poi con zoom elevato e viewport mobile.
7. In DevTools, controlla cookie e richieste di rete prima del consenso e dopo ciascuna scelta. Nessun tracker soggetto a consenso dovrebbe avviarsi anticipatamente.

Uno scanner automatico può rilevare problemi di semantica, contrasto e nomi accessibili. Non può però stabilire da solo se il focus venga gestito correttamente in ogni passaggio o se la CMP rispetti le scelte registrate: servono prove manuali e verifica dei tracciamenti effettivi.

La verifica automatica è utile, ma non sostituisce una prova pratica.

Checklist per scegliere una CMP accessibile prima dell’acquisto

Valuta la CMP sul sito reale: tema, plugin e personalizzazioni possono alterarne il comportamento.

Registra versione della CMP, browser, tecnologia assistiva, problemi e risultati del test.

Checklist operativa prima della pubblicazione della CMP

Usa questi controlli rapidi per documentare una prova sul sito reale:

Domande frequenti sui cookie banner accessibili

Accessibilità e consenso: una verifica da fare insieme

Il cookie banner è spesso la prima interazione con un sito. Se nasconde il focus, la barriera compare prima ancora di raggiungere il checkout.

MyAccessible può aiutare a individuare le criticità rilevabili automaticamente e a organizzare le verifiche successive. Per valutare focus, tastiera, screen reader e comportamento effettivo della CMP, lo scanner va affiancato a una gap analysis e a test manuali sul sito reale.

Richiedi un audit di accessibilità del tuo sito web e verifica anche il percorso di consenso: un’interfaccia accessibile deve permettere di scegliere, non costringere a scegliere in un solo modo.