Perché accessibilità e consenso ora si sovrappongono

Il GDPR richiede che il consenso possa essere ottenuto da ogni utente, non solo da coloro che possono vedere e fare clic su un banner. Il Comitato europeo per la protezione dei dati ha chiarito che se un interessato non può interagire significativamente con l'interfaccia di consenso — a causa di una disabilità che il sito non ha accomodato — il consenso non è validamente ottenuto. Ciò significa che i cookie non avrebbero mai dovuto essere caricati in primo luogo.

Sul fronte dell'accessibilità, la Legge Europea sull'Accessibilità (EAA) recepita nel diritto nazionale in tutti gli Stati Membri dell'UE rende il WCAG 2.1 AA il requisito minimo per i siti web e le app del settore privato che offrono servizi ai consumatori. Il regime sanzionatorio varia per paese ma in genere va da €50.000 a €500.000 per infrazione, più ordini di ritiro dal mercato per la non conformità persistente.

I requisiti WCAG fondamentali per i banner dei cookie

Operabilità da tastiera

Ogni controllo del banner — Accetta, Rifiuta, Gestisci preferenze, chiudi — deve essere raggiungibile e operabile solo con la tastiera. Gli utenti devono poter navigare con Tab tra i pulsanti in ordine logico e attivarli con Enter o Space. Il focus deve essere visibile con un rapporto di contrasto minimo di 3:1 rispetto allo sfondo.

Trappola del focus nei banner modali

Se il banner blocca l'interazione con il resto della pagina, il focus da tastiera deve essere intrappolato all'interno del banner finché l'utente non effettua una scelta. Gli utenti non devono poter uscire con Tab dal banner per scorrere la pagina sottostante. Quando il focus era intrappolato e il banner si chiude, il focus dovrebbe tornare all'elemento che ha attivato il banner o a un'impostazione predefinita sensata.

Annunci del lettore di schermo

Il banner deve essere annunciato come una finestra di dialogo con un nome e un ruolo accessibili. Usa `role="dialog"` o `role="alertdialog"` con `aria-labelledby` che punta all'intestazione del banner e `aria-describedby` che punta al testo esplicativo.

Contrasto dei colori

Il testo del corpo deve soddisfare un contrasto di 4,5:1 rispetto allo sfondo; il testo grande (18pt+ o 14pt grassetto) richiede 3:1. Il testo dei pulsanti, le icone e gli indicatori di focus hanno tutti i loro minimi di contrasto. Un pulsante "Rifiuta" grigio chiaro su sfondo bianco è un frequente fallimento WCAG che vediamo negli audit.

Nessun segnale basato solo sul colore

Non fare affidamento solo sul colore per distinguere Accetta da Rifiuta. Usa etichette, icone o forme distinte in modo che gli utenti daltonici possano distinguere i pulsanti.

Pattern oscuri e accessibilità

Il WCAG 2.2 introduce nuovi criteri che mirano direttamente ai pattern oscuri — particolarmente rilevanti per il consenso:

• 3.3.8 Autenticazione accessibile — vieta i puzzle cognitivi come frizione di consenso.
• 3.3.7 Inserimento ridondante — gli utenti non dovrebbero dover reinserire informazioni solo per revocare il consenso.
• 2.4.11 Focus non oscurato — il banner stesso non dovrebbe oscurare l'indicatore di focus degli elementi dietro di esso.
• 2.5.7 Movimenti di trascinamento — se il banner utilizza un'interazione drag-to-accept, deve esistere un'alternativa a puntatore singolo.

RTL e internazionalizzazione

L'accessibilità si estende alle lingue da destra a sinistra (arabo, ebraico, persiano, urdu) e alla pronuncia dei lettori di schermo:

• Imposta `dir="rtl"` sul banner quando la lingua del documento è RTL in modo che l'ordine dei pulsanti e il flusso del focus corrispondano alla direzione di lettura.
• Usa gli attributi `lang` corretti sulla copia del banner tradotta in modo che i lettori di schermo pronuncino le parole con la fonetica corretta.
• Specchia l'iconografia — frecce, chevron e indicatori di avanzamento dovrebbero capovolgersi per i locali RTL.

Testare il banner per la conformità WCAG

Non fare affidamento su un unico strumento. Combina la scansione automatizzata con il test reale con tecnologie assistive:

• axe DevTools o Lighthouse — rileva automaticamente circa il 30-40% dei fallimenti WCAG.
• NVDA o JAWS su Windows, VoiceOver su Mac/iOS, TalkBack su Android — testa con lettori di schermo reali. Il banner può essere annunciato, navigato e chiuso usando solo il lettore di schermo?
• Navigazione solo da tastiera — scollega il mouse. Se non riesci ad Accettare, Rifiutare e gestire le preferenze, nemmeno gli utenti da tastiera possono farlo.
• Simulazione del daltonismo — Chrome DevTools ha simulatori di deficit visivo integrati. Verifica che Accetta e Rifiuta siano distinguibili in caso di protanopia, deuteranopia e tritanopia.
• Zoom al 400% — il WCAG richiede che il contenuto rimanga utilizzabile al 400% di zoom senza scorrimento orizzontale. I banner a posizione fissa spesso falliscono questo test.

Fallimenti comuni di accessibilità che vediamo

• Rifiuta nascosto dietro un'icona a ingranaggio — pattern oscuro più fallimento di accessibilità (nessun nome accessibile sul pulsante icona).
• Il focus non raggiunge mai il banner — banner che rubano l'attenzione visiva ma vengono saltati nell'ordine Tab.
• Banner modale senza trappola del focus — gli utenti possono passare con Tab alla pagina di sfondo mentre il banner afferma di bloccare l'interazione.
• Nessun `aria-live` sui cambiamenti delle preferenze — gli utenti del lettore di schermo non sentono la conferma che la loro scelta è stata salvata.
• Banner tradotti senza attributo `lang` — i lettori di schermo pronunciano il testo spagnolo con fonetica inglese.

Come FlexyConsent garantisce l'accessibilità