Consenso dei cookie: come crearlo accessibile

Recentemente Roberto Scano mi ha ricordato dei problemi di accessibilità che talvolta affliggono il consenso dei cookie, tramite i banner che compaiono all’accesso di ogni sito web, cosa che Roberto ha anche segnalato in questo tweet, giustamente apprezzato e ripreso da Guido Scorza, attualmente componente Collegio Garante protezione dei dati personali

Il banner dei cookie è un oggetto molto controverso, talvolta percepito dagli utenti come inutile e privo di significato, ma anche fastidioso quasi come un banner pubblicitario indesiderato.

I problemi di accessibilità del banner di consenso dei cookie

Il fatto è che Roberto Scano ha ragione, e in una grande quantità di tali oggetti che abbiamo analizzato in questi ultimi mesi, sussistono uno o più problemi di accessibilità che talvolta diventano un vero e proprio impedimento all’utilizzo della risorsa digitale che lo ospita.

La lista delle problematiche è davvero lunga, provo a elencare le più comuni:

  • il carattere (font) con cui sono scritti è troppo piccolo rispetto al resto delle interfacce del sito stesso;
  • i colori del testo, dei pulsanti, dei bordi, non hanno sufficiente contrasto di colore rispetto ai colori adiacenti o sottostanti;
  • il link di collegamento alle risorse esplicative (il classico “leggi tutto”) non ha sufficiente semantica (markup) per essere individuato, come ad esempio l’assenza della sottolineatura permanente;
  • i pulsanti di accettazione o di annullamento non sono identificati semanticamente come tali e sono solo “visivamente” pulsanti con i quali non si può interagire con le tecnologie assistive come i lettori di schermo;
  • il pulsante di accettazione non è semanticamente legato al testo che lo segue o lo precede;
  • mancanza di un pulsante di annullamento qualora si decida di proseguire la navigazione senza acconsentire all’uso dei cookie;
  • la call-to-action sull’accettazione è talvolta ambigua o utilizza etichette considerate sinonimi ma che invece possono assumere significati diversi: vai, accetta, ok, continua, conferma, vedi, ecc.;
  • la call-to-action di accettazione è talvolta non distinguibile da quella di annullamento (es: “continua”, per proseguire senza accettare e “vai” per accettare);
  • la dimensione e la forma del banner è talmente uniformata al resto del sito che l’utente non ne percepisce la presenza;
  • viceversa, il banner è talmente invasivo che occlude la visione dei contenuti in maniera quasi totale.

Perché renderlo accessibile

Il banner dei cookie non è affatto un oggetto innocuo e privo di significato, per questo il Garante pone ancora oggi molta attenzione a questa tematica. 

Creare un banner accessibile è quindi molto importante per tutti gli utenti, ma diventa di fondamentale importanza per gli utenti che necessitano dei requisiti di accessibilità per poter usufruire delle risorse web.

Per creare un banner dei cookie accessibile, in teoria, non ci sono troppe cosa da sapere né da dire, infatti basterebbe ricordare che deve essere realizzato rispettando i punti delle WCAG 2.1, (riferimento attuale per la creazione dei contenuti accessibili) che sono coinvolti nelle interfacce utente presenti nel banner stesso (link, pulsanti, ecc).

Tuttavia ci sono alcuni punti che, seppure compresi all’interno dei Criteri di Controllo delle WCAG stesse, possono sfuggire a molti ideatori di interfacce web e molti sviluppatori. Di seguito sono riportati alcuni punti di riflessione di fondamentale importanza per creare un banner accessibile.  

Il flusso logico

L’assunto è che il banner dei cookie deve essere la prima cosa che l’utente incontra appena inizia la consultazione di un nuovo sito web.

Per questo motivo l’oggetto HTML che rappresenta il banner dovrebbe trovarsi nel flusso logico della DOM della pagina al primo posto, ad esempio subito dopo l’apertura dell’elemento <body>, in modo che le tecnologie assistive possano avere un comportamento analogo a ciò che avviene dal punto di vista visivo.

Molto spesso dal punto di vista visivo, il banner viene collocato a fondo pagina e tale collocazione sta diventando quasi uno pseudo-standard. Non c’è una problematica di accessibilità in tal senso, in quanto, seppur visivamente a fondo pagina, il banner può essere lasciato come primo elemento della DOM e può essere collocato visivamente in basso agendo soltanto sui fogli di stile. 

Ci sono molti modi per realizzare tale struttura, talvolta naviti nei vari framework, ma come ragionamento di partenza possono essere utilizzate le proprietà fixed o sticky.

Aggiungere adeguata semantica

Il banner dei cookie dal punto di vista semantico non è un oggetto neutro e deve essere distinguibile dal resto dei contenuti, pertanto non può essere un normale elemento <div> o <p>, come se fosse un paragrafo qualunque della pagina web.

Una prima strada per risolvere questo problema è quella di assegnare all’elemento contenitore un ruolo di alert (role=”alert”) in modo che le tecnologie assistive possano comunicare immediatamente all’utente la presenza di tale funzionalità. Questo ruolo in associazione a una corretta etichettatura, conferisce all’oggetto la necessaria priorità di cui anche visivamente si percepisce l’esistenza.

<div … role=”alert” aria-label=”banner dei cookie”> [...] </div>

Per dare ancora più evidenza semantica all’oggetto sarebbe anche opportuno assegnare all’oggetto <div> un ruolo più significativo, marcando la sezione HTML contenitore come una Region Landmark, ad esempio:

<section aria-labelledby="my-cookie">
   <h2 id="my-cookie">Cookie</h2> 
   … contenuto ...
</section> 

Utilizzando un codice di questo tipo si permetterebbe ai lettori di schermo di rintracciare facilmente la sezione “cookie” e di ritrovarla facilmente nei riepiloghi della pagina. 

La responsività (desktop e mobile)

È importante verificare che la soluzione web creata per i dispositivi desktop sia adatta anche ai dispositivi mobili. Troppo spesso infatti in modalità mobile il banner diventa completamente ingestibile e impossibile da accettare e/o eliminare. 

In questo caso non è possibile fornire un’indicazione precisa su porzioni di codice o strategie da utilizzare. 

È importante che gli sviluppatori tengano ben presente questo task e che agiscano, se necessario, attraverso le media-query dei proprio fogli di stile per risolvere questo tipo di problema.

Le etichette

Come detto in fase di elencazione degli errori troppo spesso le etichette che definiscono le call-to-action del banner dei cookie sono ambigue e non esplicative. 

Il banner dei cookie, come indicato dall’autorità Garante, esprime una funzione di acquisizione di consenso: “… rendere l’informativa online agli utenti della rete e acquisire, quando necessario, il loro consenso”.

In questo contesto è pertanto importante semplificare l’etichetta della call-to-action in modo che esprima chiaramente tale concetto, e l’utilizzo di “acconsento” o “accetto” in accordo a quanto riportato nei testi precedenti o seguenti, sembrano a tutt’oggi le strade più accessibili.

Sono comunque da evitare etichette generiche non contestualizzate come ad esempio “ok”, “vai”, “continua”.

Opzioni supplementari

La normativa impone ai costruttori di progetti web “una ulteriore area dedicata nella quale sia possibile selezionare, in modo analitico, soltanto le funzionalità, i soggetti cd. terze parti – il cui elenco deve essere tenuto costantemente aggiornato – ed i cookie, anche eventualmente raggruppati per categorie omogenee, al cui utilizzo l’utente scelga di acconsentire”.

È importante ravvisare che tale area, a tutt’oggi, rappresenta spesso un complicato ginepraio di terminologie e oggetti di design che non rendono affatto comprensibile lo scopo di tali funzionalità aggiuntive.

In alcuni casi gli autori decidono di pubblicare in banner dei cookie in maniera più dominante, facendo in modo di impedire la consultazione del sito fino a quando l’utente non avrà selezionato i cookie; tale funzionalità talvolta è realizzata attraverso layer che ricordano le finestre modali. A tale proposito si ricorda che le funzionalità accessibili per le finestre modali sono descritte in questo tutorial del W3C, e che si può prendere come riferimento anche la modale di Bootstrap.

È importante sottolineare che anche queste sezioni devono rispettare pienamente i principi di accessibilità espressi dalle WCAG 2.1, per evitare che il necessario adempimento diventi un’area oscura, più di quanto siano oscuri i concetti di cookie che invece intende esplicitare.

Condividi:

Fabrizio Caccavello

Web Accessibility Expert - User Experience Designer. Mi occupo di standard, accessibilità e strategie per il web, di HTML/CSS e di sviluppo di applicazioni desktop e mobile. Mi impegno nello studio della semplificazione dei layout come valore aggiunto e imprescindibile nello sviluppo di progetti accessibili e conformi agli standard.
Mi occupo di Responsive Web Design, tecnica di progettazione per il web multipiattaforma e multi device.
Consulente Super Senior in Accessibilità in Agenzia per l'Italia Digitale
Membro della commissione e-Accessibility di UNINFO e coordinatore del gruppo di lavoro "Traduzioni e adozioni"
Membro del Consiglio direttivo di IWA-Italy
Fondatore di Akebia - internet experience