Questo post ha un titolo piuttosto provocatorio, “Accessibilità e cookie banner WordPress: la verità”, ma sinceramente non riesco a trovare un’altra frase breve che descriva meglio il contenuto.
La verità è che sono frustrato dai plugin e dai servizi SaaS di WordPress che dichiarano di essere accessibili quando, in realtà, non lo sono.
Nel caso dei cookie banner — obbligatori per legge in molte parti del mondo — queste false affermazioni di accessibilità possono mettere il proprietario del sito non solo dalla parte sbagliata delle leggi sull’accessibilità, ma anche di quelle sulla privacy.
Le leggi sulla privacy in tutto il mondo richiedono ai siti web di fornire informazioni chiare e trasparenti sui dati raccolti dagli utenti, oltre a offrire agli utenti la possibilità di acconsentire o rifiutare il tracciamento.
Esempi di leggi sui banner cookie
Unione Europea: GDPR & Direttiva ePrivacy
Regolamento Generale sulla Protezione dei Dati (GDPR) (2018): Richiede ai siti web di ottenere un consenso esplicito, informato e revocabile prima di memorizzare cookie non essenziali.
Direttiva ePrivacy (Cookie Law) (2002, aggiornata nel 2009): Impone di informare gli utenti sull’uso dei cookie e di dare loro la possibilità di accettarli o rifiutarli.
Regno Unito: UK GDPR & PECR
UK GDPR (2021, versione post-Brexit del GDPR): Segue gli stessi principi del GDPR europeo.
Privacy and Electronic Communications Regulations (PECR): Richiede un consenso chiaro e informato prima di posizionare cookie sui dispositivi degli utenti.
Stati Uniti: leggi sulla privacy a livello statale
Negli USA non esiste una legge federale che imponga i banner cookie, ma diversi stati richiedono trasparenza sulla raccolta dei dati. Gli stati richiedono tipicamente alle aziende di informare se raccolgono dati degli utenti e di offrire un’opzione per rifiutare la vendita o la condivisione delle informazioni personali (non un consenso esplicito come il GDPR).
Esempi di leggi statali:
California Consumer Privacy Act (CCPA) e aggiornamento CPRA (2023)
Colorado Privacy Act (CPA)
Connecticut Data Privacy Act (DPA)
Utah Consumer Privacy Act (UCPA)
Virginia Consumer Data Protection Act (CDPA)
Canada: PIPEDA
Personal Information Protection and Electronic Documents Act (PIPEDA): Richiede di ottenere un consenso significativo per la raccolta dei dati personali, inclusi i cookie.
Le leggi sulla privacy si applicano a tutti gli utenti
Se la legge ti obbliga a informare gli utenti sui cookie presenti sul tuo sito, tale informativa deve essere accessibile a tutti gli utenti, non solo ad alcuni o agli “utenti tipici” che possono usare il mouse.
Se un banner cookie non è leggibile dai lettori di schermo, non supporta la navigazione da tastiera o ha un contrasto insufficiente, gli utenti con disabilità potrebbero non riuscire a fornire un consenso valido, esponendo l’azienda a rischi di non conformità e possibili sanzioni.
Joe Dolson conduce un podcast mensile sull’accessibilità insieme a Nathan Wrigley di WP Builds. In ogni episodio, Joe analizza l’accessibilità di un componente specifico su diversi siti presenti nel WordPress Showcase, evidenziando dove vengono commessi errori.
È un’analisi approfondita che offre spunti concreti per capire le aspettative sull’accessibilità, componente per componente.
Nel quarto episodio del podcast Accessibility Show condotto da Joe Dolson, il tema trattato sono stati i banner cookie. In questa puntata, Joe analizza tre diversi banner cookie provenienti da tre plugin differenti.
Tutti risultano insufficienti nei test di accessibilità di base e uno di essi non può nemmeno essere configurato usando il mouse!
Dopo aver visto Joe discutere dei problemi di questi banner, potresti chiederti come si comporta il tuo banner cookie.
Oppure, magari ti senti sicuro che il tuo banner rispetti le leggi sulla privacy e sull’accessibilità, perché hai già valutato la cosa e scelto con attenzione un banner che prometteva accessibilità.
Beh, mi dispiace deluderti, ma…
Tra i plugin per cookie più installati su WordPress.org, solo Cookie Compliance di Hu-manity non menziona affatto l’accessibilità.
La maggior parte degli altri plugin e servizi SaaS più diffusi promettono accessibilità, sia con una breve frase che con una pagina intera dedicata al tema.
Purtroppo, queste promesse non sempre vengono rispettate.
Dichiarazioni di accessibilità di Complianz
Complianz conta oltre un milione di installazioni attive. Nella pagina del plugin su WordPress.org, si afferma che il loro banner per il consenso ai cookie è “conforme a WCAG Level AA e ADA” e che “i banner cookie e i documenti legali rispettano le linee guida di accessibilità WCAG 2.1 AA e la conformità ADA”.
Dichiarazioni di accessibilità di CookieYes
Il plugin CookieYes conta anch’esso oltre un milione di installazioni attive. Nella pagina del plugin su WordPress.org si legge: “Accessibilità: il banner è conforme a WCAG/ADA per l’accessibilità.”
Questo testo è stato aggiunto a settembre 2025. In precedenza, CookieYes non dichiarava di essere conforme a WCAG e ADA né di essere accessibile.
Dichiarazioni di accessibilità di Moove GDPR Cookie Compliance
Il plugin GDPR Cookie Compliance conta 300.000 installazioni attive. Sul sito del plugin, le funzionalità sono elencate con delle spunte invece dei punti elenco. Una delle funzionalità recita: “Accessibilità WCAG & ADA”.
Non ci sono altre informazioni sull’accessibilità del plugin GDPR Cookie Compliance sul sito.
Nella pagina del plugin su WordPress.org si afferma che il plugin è “Ottimizzato secondo le linee guida di accessibilità WCAG e ADA.”
Dichiarazioni di accessibilità di Real Cookie Banner
Il plugin Real Cookie Banner di DevOwl conta oltre 100.000 installazioni attive. Nella pagina del plugin su WordPress.org viene promessa l’accessibilità, e nella loro knowledge base è presente un articolo che ne discute in dettaglio.
In questo articolo della knowledge base si legge: “Real Cookie Banner è accessibile a partire dalla versione 3.10.” Proseguendo, l’articolo afferma:
“Abbiamo allineato Real Cookie Banner al rinomato standard WCAG 2.2 in termini di percepibilità, usabilità, comprensibilità e robustezza, rendendolo, a nostro avviso, accessibile secondo la Legge europea sull’accessibilità.”
Dichiarazioni di accessibilità di CookieAdmin
Il plugin CookieAdmin conta oltre 100.000 installazioni attive. Nella pagina del plugin su WordPress.org, tra le funzionalità gratuite viene indicato: “Conforme a ADA, EAA e WCAG.”
Dichiarazioni di accessibilità di Usercentrics
Nota: la versione di Usercentrics citata in questo articolo è quella disponibile tramite abbonamento a pagamento sul sito di Usercentrics, non il plugin gratuito WordPress Usercentrics CookieBot.
Secondo BuiltWith, Usercentrics conta 613.772 installazioni attive. Sul footer del proprio sito web, Usercentrics mostra un badge che dichiara “WCAG 2.1 Certified Web Content Accessibility Guidelines”.
Il badge rimanda a una pagina web dedicata all’accessibilità di Usercentrics, che include affermazioni del tipo:
“La certificazione Web Content Accessibility Guidelines (WCAG) è considerata lo standard di riferimento per l’accessibilità web.”
e
“Tutti i livelli del banner cookie di Usercentrics, per tutti i nostri piani, sono stati testati rispetto ai requisiti di conformità WCAG 2.1 AA e li hanno superati.”
Se fossi un proprietario di sito o uno sviluppatore web che vuole fare le cose per bene, cercherei un plugin per i cookie che dichiarasse di essere accessibile.
Trovarne uno certificato dalle Web Content Accessibility Guidelines sembrerebbe ancora meglio. Ovviamente, sceglierei quello.
Tranne che…
Non esiste una vera e propria “certificazione WCAG”.
Le Web Content Accessibility Guidelines (WCAG) sono un insieme di standard internazionalmente riconosciuti per misurare l’accessibilità di siti web, software e contenuti digitali. Questi standard sono sviluppati da organizzazioni e volontari di tutto il mondo attraverso il World Wide Web Consortium (W3C).
Il W3C sviluppa standard, non “certifica” siti web o software per l’accessibilità.
Quel badge sul sito di Usercentrics è, nella migliore delle ipotesi, fuorviante, perché non specifica chi li abbia certificati, o, nel peggiore dei casi, totalmente inventato, visto che nessuno li ha effettivamente certificati.
Qualsiasi plugin che dichiari di essere conforme alle WCAG usa la terminologia corretta; tuttavia, se un’azienda non specifica come sa che le sue soluzioni rispettano le WCAG, è legittimo mettere in dubbio la validità di tali affermazioni.
Se non ci sono informazioni su chi ha condotto i test di accessibilità, quali strumenti sono stati utilizzati e se persone con disabilità sono state coinvolte nei test, questo è un forte segnale di allarme.
La verità sull’accessibilità dei banner cookie di WordPress è che non ne ho trovato nessuno realmente conforme alle WCAG senza necessitare almeno di qualche intervento correttivo, e molti presentano gravi carenze nonostante dichiarino la conformità alle WCAG.
A febbraio 2025, il team del sito WP Accessibility Day ha testato diversi banner cookie nel tentativo di trovare una soluzione adatta all’uso sul sito della conferenza. Purtroppo, nessuna delle soluzioni esaminate rispettava i requisiti legali di accessibilità previsti da leggi come la European Accessibility Act, l’ADA o la Section 508. Tutte presentavano errori di accessibilità e non conformità alle WCAG, nonostante dichiarassero ampiamente di essere conformi.
La versione originale di questo articolo riportava i risultati dei test effettuati a febbraio 2025. Successivamente, è stata aggiornata con ulteriori test.
I plugin elencati di seguito sono stati tutti testati da Alex Stine, esperto di accessibilità non vedente, il 24 settembre 2025, durante un WordPress Accessibility Meetup.
La registrazione di quell’incontro è disponibile qui: WordPress Accessibility Meetup: Cookie Banner Accessibility Testing e mostra molti, ma non tutti, i problemi elencati di seguito.
Problemi di accessibilità di Complianz
Versione testata: 7.4.2
Errori di accessibilità:
Mancanza di blocco del tab focus per il dialogo.
Nella visualizzazione delle preferenze, componenti interattivi annidati (toggle button all’interno del tag
<summary>).Cliccando su Accetta si perde il focus. Il focus dovrebbe tornare al skip link la prima volta o reindirizzare al pulsante Gestisci Consenso se quello era il trigger del dialogo.
Il pulsante Gestisci consenso manca di aria-haspopup e aria-controls.
Non conforme a 1.4.10 Reflow, perché il contenuto va perso con lo zoom al 400%.
Errori di usabilità / possibili problemi:
I link alle policy sono posizionati dopo i pulsanti Accetta/Rifiuta e potrebbero essere ignorati.
Potrebbe essere meglio posizionare il pulsante Gestisci consenso in cima al DOM; in fondo è più difficile da trovare per gli utenti.
Alex non si aspettava che il pulsante Salva Preferenze chiudesse la finestra modale, ma solo il contenuto salvato. Questo ha creato confusione tra i pulsanti Accetta e Salva.
Problemi di Mostra/Nascondi rilevati già a partire da febbraio 2025.
Problemi di accessibilità di CookieYes
Versione testata: 3.3.5
Errori di accessibilità:
Il focus non viene spostato sul banner, che viene caricato sopra la posizione corrente del focus (skip link). Il banner viene caricato dopo che il focus del lettore di schermo è già impostato e non viene annunciato, rendendo molto difficile individuarlo; gli utenti devono risalire la pagina per trovarlo.
È contenuto in un region landmark anziché in un dialogo. Questo non crea problemi per un utente di screen reader, ma viola 1.3.1 Info e Relazioni, perché la presentazione visiva non corrisponde alla semantica e al comportamento accessibile, e può causare altri problemi. Se si usa un ruolo region, il banner non dovrebbe sovrapporsi ad altri contenuti.
Mancanza di tab focus lock sul dialogo, permettendo agli utenti di interagire con la pagina senza fare una selezione o chiudere il modale. Questo può generare errori di 2.4.11 Focus Not Obscured (Minimum), poiché gli elementi dietro il modale possono ricevere il focus senza essere visibili.
Le etichette dei pulsanti sono insufficienti, dato che si trova in un region e non in un dialogo. I pulsanti leggono “Accetta tutto” senza il contesto “Accetta tutti i cookie”. L’uso di un region permette al contenuto di mescolarsi con il resto della pagina, quindi i controlli devono essere più specifici.
Il pulsante Personalizza manca di aria-haspopup e aria-controls.
I pulsanti dell’accordion non leggono la descrizione se si naviga con il tasto Tab; necessitano di aria-describedby.
Cliccando su Salva Preferenze, il focus ritorna su un “gruppo” ed è poco chiaro dove ci si trovi nella pagina.
Il pulsante per le preferenze di consenso manca di aria-haspopup e aria-controls.
Il pulsante Mostra di più nel dialogo non sposta il focus sul contenuto appena rivelato. Il focus si perde completamente quando il pulsante viene rimosso dal DOM dopo un clic.
Errori di usabilità / possibili problemi:
L’intestazione nel banner è un H1. Non è un errore WCAG, ma come best practice, dovrebbe esserci un solo H1 per pagina.
CookieYes è stato testato per la prima volta a settembre, quindi non ci sono problemi da confrontare con quelli di febbraio 2025.
Problemi di accessibilità di Moove GDPR Cookie Compliance
Versione testata: 5.0.8
Errori di accessibilità:
Il banner non riceve il focus né notifica agli utenti di screen reader che è disponibile per accettare o rifiutare i cookie. Si trova in un complementary landmark in fondo alla pagina e manca un’intestazione. Per un utente di screen reader, la possibilità di individuare questo banner è circa il 10%, secondo Alex.
Mancanza di tab focus lock, permettendo agli utenti di interagire con la pagina senza fare una selezione o chiudere il modale. Questo consente agli elementi dietro il banner di ricevere il focus pur essendo nascosti.
Il pulsante Cambia impostazioni cookie ha
aria-haspopup="true", valore errato; viene annunciato come un menu. Il valore corretto dovrebbe essere dialog.I controlli e i pannelli nella finestra di dialogo delle impostazioni mancano di tutti gli attributi ARIA richiesti.
I campi di input sono nascosti con
display:none, quindi non possono ricevere il focus da tastiera e non sono funzionali per gli utenti keyboard.Mancano markup di intestazione per i titoli (sono presenti solo paragrafi o span stilizzati come titoli).
Il focus non viene gestito alla chiusura del dialogo.
Gli indicatori di focus nella finestra di dialogo sono mancanti o insufficienti.
Il contenuto del modale viene tagliato o perso quando si applica uno zoom al 200% o 400%.
Il colore è l’unico elemento usato per distinguere gli stati default e hover.
Problemi di Mostra/Nascondi rilevati già da febbraio 2025.
Questi problemi sono stati segnalati da nel forum di supporto WordPress di GDPR Cookie Compliance. Tutti i problemi, tranne uno, risultano irrisolti al 30 settembre 2025.
Altri problemi rilevati:
Il dialogo cookie manca degli attributi ARIA richiesti.
Gli indicatori di focus nel dialogo sono mancanti o insufficienti.
I pulsanti che aprono modali mancano di aria-haspopup.
Il contenuto del modale viene tagliato o perso con lo zoom al 200%.
Navigando tra le schede delle impostazioni, si verifica un cambio di contesto automatico e inaspettato, che può disorientare l’utente e interrompere il flusso di lavoro.
I toggle button non sono raggiungibili da tastiera né cliccabili senza mouse.
Il contenuto che appare visivamente quando si interagisce con i toggle non viene annunciato dagli screen reader.
Le schede delle impostazioni non sono definite programmaticamente come tab né etichettate come tali per gli screen reader.
I link alla privacy policy e al sito di GDPR Cookie Compliance non sono raggiungibili da tastiera né cliccabili senza mouse – risolto.
Problemi di accessibilità di Real Cookie Banner
Versione testata: 5.2.1
Errori di accessibilità:
Il focus non si sposta sul banner al caricamento iniziale della pagina. Il banner cookie è posizionato sopra la posizione corrente del focus (skip link) ed è stato caricato dopo che il focus dello screen reader era già impostato.
L’ordine del focus non corrisponde all’ordine visivo. Va su “Continua senza consenso”, poi “Accetta tutto”, quindi “Imposta le impostazioni sulla privacy individualmente”, fuori ordine rispetto alla pagina.
Mancano intestazioni per le diverse sezioni del dialogo. Alex ha notato che il dialogo è difficile da navigare a causa della quantità di testo, della scarsa suddivisione (molti div anziché liste o altri contenitori semantici) e dell’assenza di intestazioni.
Non conforme a 1.4.10 Reflow, perché elementi sticky rendono impossibile leggere il contenuto del dialogo con zoom al 400%.
Errori di usabilità / possibili problemi:
Il link “Salta alle scelte del consenso” non porta l’utente al punto previsto quando si personalizzano le scelte. Alex si aspettava che andasse direttamente alle impostazioni di personalizzazione e non ai controlli generali. Vista la quantità di testo nel banner, servirebbe un modo per saltare direttamente a quei controlli.
Alex ha notato che avere il pulsante Salva in cima è molto fastidioso, perché è difficile da trovare, soprattutto in un dialogo con così tanto contenuto. Non vuole dover scorrere tutti i controlli per configurarli e poi tornare indietro per trovare il pulsante Salva.
Problemi di Mostra/Nascondi rilevati già da febbraio 2025.
Problema segnalato sul forum di supporto WordPress di Real Cookie Banner. Tutti i problemi, tranne uno, risultano risolti al 30 settembre 2025.
Altri problemi rilevati:
Il dialogo non riceve il focus in modo consistente al caricamento – ancora presente.
L’intestazione del modale dovrebbe essere un H2 invece di un H3.
Il tag
<dialog>necessita diaria-modal="true".I link Mostra informazioni sul servizio (e altri simili) che espandono contenuto nascosto devono essere pulsanti.
I pulsanti per mostrare informazioni sul servizio (attualmente codificati come
<a>) dovrebbero avere nomi univoci.I middot devono essere nascosti agli screen reader con
aria-hidden="true"o tramite CSS (meglio).Tutti i link trasformati in pulsanti con
role="button"devono avere gestori per la barra spaziatrice, così da poterli attivare con essa.Quando lo stile del link è sottolineato, la sottolineatura dovrebbe sparire al passaggio del mouse, così da non usare solo il colore per indicare lo stato hover.
Problema di ordine del focus dopo l’espansione delle impostazioni individuali: il link per configurare le impostazioni individuali viene rimosso dal DOM al clic, facendo perdere il focus da tastiera. Il pulsante delle impostazioni individuali dovrebbe rimanere visibile nel modale e tutti i nuovi contenuti aggiunti dovrebbero essere introdotti dopo di esso (come un accordion).
Le checkbox delle scelte di consenso leggono l’etichetta tre volte, perché sono troppo complesse nella loro implementazione.
Problemi di accessibilità di CookieAdmin
Versione testata: 1.1.0
Errori di accessibilità:
Il modale non riceve il focus da tastiera e non viene annunciato agli utenti di screen reader all’apertura.
Mancanza totale di un landmark region per il modale; si trova in fondo alla pagina e mancano tutti gli attributi ARIA previsti per i dialoghi. Alex ha stimato che la possibilità di individuare questo banner è circa il 5%, quindi la maggior parte degli utenti non vedenti non saprà mai che esiste.
Mancanza di tab focus lock, permettendo agli utenti di interagire con la pagina senza fare una selezione o chiudere il modale. Questo consente agli elementi dietro il banner di ricevere focus pur essendo nascosti.
Mancano markup di intestazione per i titoli (sono presenti solo paragrafi o span stilizzati come titoli).
Il link “powered by” manca di un nome accessibile per l’immagine.
Il pulsante Personalizza manca di aria-haspopup e aria-controls.
Il modale Personalizza le tue preferenze sui cookie manca del ruolo dialog, del nome accessibile e degli attributi ARIA per il dialogo.
All’apertura del modale, il focus va in una posizione casuale al centro del dialogo.
Il pulsante di chiusura manca di nome accessibile.
Il paragrafo al centro del dialogo ha erroneamente il ruolo dialog.
Il pulsante Mostra di più non sposta il focus sul testo appena rivelato.
Mancanza di tab focus lock nel modale Personalizza le tue preferenze sui cookie.
Gli accordion per i diversi tipi di cookie mancano di pulsanti per aprirli e chiuderli – sono
<span>con un’icona; senza nome accessibile, non tab-focalizzabili e mancaaria-expanded.Le informazioni sui cookie sono confuse e prive di struttura significativa – sono solo div. Sarebbe meglio utilizzare una tabella.
I campi di input sono nascosti con
display:none, quindi non ricevono il focus da tastiera e non sono funzionali da tastiera.I campi di input non hanno etichetta.
La chiusura del modale provoca perdita totale del focus.
Non conforme a Reflow, perché elementi sticky rendono impossibile leggere il contenuto del dialogo con zoom al 400%.
CookieAdmin è stato testato per la prima volta a settembre, quindi non ci sono problemi da confrontare con quelli di febbraio 2025.
Problemi di accessibilità di Usercentrics
Versione testata: sconosciuta. Non è un plugin WordPress, quindi non esiste un numero di versione noto. I problemi riportati sono aggiornati al 30 settembre 2025.
Errori di accessibilità:
Il pulsante Essenziale è disabilitato e nascosto con
aria-hidden, quindi gli utenti di screen reader non possono trovarlo né sapere che alcuni cookie essenziali vengono impostati.I pulsanti “Visualizza dettagli servizio” mancano di etichette univoche.
I pulsanti “Visualizza dettagli servizio” mancano di aria-haspopup e aria-controls.
I modali “Visualizza dettagli servizio” mancano del ruolo dialog, del nome accessibile e degli attributi ARIA per dialogo.
Il pulsante Salva impostazioni provoca perdita del focus.
Il pulsante Privacy Settings che apre e chiude il dialogo si trova in un div con role="dialog", anche se non è un dialogo. Il nome accessibile del div è anch’esso “privacy settings”, creando confusione e ripetizione.
Chiudere il dialogo provoca perdita del focus.
Gli elementi con role="button" non possono essere attivati con la barra spaziatrice.
Errori di usabilità / possibili problemi:
Il pulsante Dettagli è ambiguo; Alex suggeriva un’etichetta più chiara, ad esempio “Dettagli su cosa?”.
Ogni accordion ha un ruolo region, eccessivamente rumoroso per gli screen reader e non conforme alle aspettative degli accordion. In generale, Alex ha notato un uso eccessivo di ARIA.
Tutti i pulsanti di chiusura dicono “Close Layer”, cosa insolita e confondente; normalmente sarebbe “Close dialog”, “Close modal” o semplicemente “Close”.
Quasi in violazione di Reflow a causa di componenti sticky, overlay gradient e alcuni elementi leggermente tagliati a zoom 400%. Usabile, ma migliorabile.
Queste problematiche sono state segnalate a Usercentrics tramite il forum di supporto del loro plugin. Alcune sono state risolte, ma diverse rimangono ancora irrisolte.
Problemi ancora presenti:
Le “checkbox” non sono checkbox, ma pulsanti con
role="switch"e attributiaria-checked. Usanoaria-labelledbyper l’etichetta associata, ma l’etichetta non è cliccabile perché è un pulsante, non una checkbox.I link si aprono in una nuova scheda senza indicazione.
Il nome accessibile del pulsante di chiusura è “close layer”, probabilmente confondente.
I toggle o i pulsanti singoli devono essere più grandi; il Target Size Minimum richiede almeno 24×24 px. I pulsanti info e i toggle nelle categorie non rispettano questa dimensione minima.
Alcuni pulsanti hanno
aria-labelduplicato rispetto al contenuto interno; generalmente non è un problema, ma potrebbe causare violazioni del nome accessibile.Dopo aver chiuso il dialogo, sembra che il focus vada in cima alla pagina, ma in realtà il prossimo tab stop va al pulsante flottante per aprire il dialogo e poi alla barra degli indirizzi del browser, saltando l’intero sito.
Problemi risolti:
Il dialogo era senza etichetta, causando la lettura del contenuto da parte dello screen reader all’apertura invece del solo nome. Ora gli screen reader leggono correttamente il nome.
Uso eccessivo di
tabindex=0, che rendeva alcuni elementi focusabili senza motivo, è stato corretto.Il layout del form si rompeva a zoom 200%; ora la regione scorre per rendere visibili i controlli, anche se l’interazione resta complessa.
I toggle possono essere attivati/disattivati con la barra spaziatrice alla prima ricezione del focus; successivamente la barra spaziatrice non annulla più l’azione ma scrolla la pagina sottostante. Ora bisogna tabulare fuori e tornare per riattivare il toggle.
Dopo aver modificato le impostazioni con barra spaziatrice o invio, se si preme tab per andare al toggle o link successivo, il focus ritorna all’intestazione Privacy Settings e occorre tabulare di nuovo attraverso i componenti.
Il link Usercentrics non aveva identificazione come link; ora corretto.
Cliccando un pulsante info nelle categorie, la visualizzazione scorre alla scheda del servizio selezionato, ma il focus da tastiera non viene impostato lì; lo screen reader legge dall’inizio della scheda servizi, non sull’elemento desiderato.
Una delle principali osservazioni emerse dai test è stato l’uso massiccio di ARIA nel tentativo di migliorare l’accessibilità. Non sto scrivendo questo articolo per dire che gli sviluppatori di questi plugin non abbiano provato: al contrario, è evidente che diversi di loro abbiano già investito tempo e impegno nel cercare di risolvere i problemi di accessibilità, come dimostra ad esempio l’uso del ruolo role="button".
Ma allora perché così tanti plugin per banner cookie presentano ancora problemi di accessibilità, nonostante l’impegno degli sviluppatori?
La ragione è che rendere un prodotto accessibile a posteriori è sempre più complesso e richiede molto più lavoro. Il momento migliore per integrare l’accessibilità è dall’inizio del processo di sviluppo, e il modo più efficace per farlo è utilizzare componenti semantici.
Dal codice HTML è evidente che questi plugin non sono stati progettati con l’accessibilità come priorità. Ad esempio, non sono stati usati fin da subito tag <button>, e ora si fa grande affidamento su ARIA e JavaScript per simulare la semantica e le funzionalità di un vero pulsante.
Questo non significa che non possano diventare accessibili, ma implica che sarà necessario un lavoro aggiuntivo e soprattutto test accurati e continui.
Dopo aver testato diversi plugin per il consenso ai cookie (alcuni anche due volte in un periodo di sei mesi) e aver ricevuto feedback diretti dagli sviluppatori, è emersa una realtà importante da chiarire: molti strumenti che si presentano come “accessibili” o “WCAG compliant” non lo sono davvero.
Spesso non si tratta di cattiva fede, ma di mancanza di competenze specifiche o di un’eccessiva fiducia nei test automatizzati. Alcuni team credono che essere “quasi accessibili” sia sufficiente, ma in ambito legale ed etico questo approccio non regge. Quando un plugin viene promosso come “WCAG compliant”, “ADA accessible” o “certified accessible”, tali etichette creano aspettative precise che devono essere supportate da risultati concreti.
Il problema è che in molti casi la conformità dichiarata supera di gran lunga ciò che il prodotto effettivamente offre.
E questo può avere conseguenze reali sia per gli utenti con disabilità, che vengono esclusi, sia per i proprietari dei siti web, che rischiano sanzioni o contestazioni.
Non conosciamo le intenzioni di chi sviluppa questi strumenti: alcuni potrebbero esagerare consapevolmente le proprie affermazioni per motivi commerciali, altri invece agiscono in buona fede ma senza il supporto di esperti in accessibilità.
In entrambi i casi, il risultato è lo stesso — una forte discrepanza tra le promesse del marketing e l’esperienza reale dell’utente.
L’accessibilità non può essere trattata come una voce da spuntare o un vantaggio promozionale: è un impegno tecnico e morale che richiede test accurati, trasparenza e responsabilità.
Se un plugin WordPress per la gestione dei cookie dichiara di essere conforme alle WCAG, deve poterlo dimostrare con prove concrete: documentazione dei test effettuati, dichiarazione chiara delle limitazioni e, idealmente, una validazione da parte di professionisti dell’accessibilità e di utenti reali con disabilità.
Cosa puoi fare?
Se stai utilizzando uno di questi plugin — o un altro plugin per la gestione dei cookie non menzionato — potresti chiederti quali passi intraprendere per garantire che il tuo banner rispetti le normative sulla privacy e sull’accessibilità.
Ecco alcuni consigli pratici.
1. Testa manualmente la tua soluzione per il consenso ai cookie
È fondamentale eseguire test manuali di accessibilità sui componenti del tuo sito web. Gli strumenti automatizzati, come Accessibility Checker, possono velocizzare il processo di analisi, ma non rileveranno errori strutturali come un <div> usato al posto di un <input>, interazioni che causano la perdita del focus da tastiera o etichette errate negli elementi interattivi.
Spegni il mouse, attiva un lettore di schermo e prova a utilizzare il tuo banner per i cookie solo con la tastiera. Verifica di poter ascoltare tutte le informazioni, raggiungere ogni elemento interattivo e riuscire ad accettare o rifiutare il consenso.
Indipendentemente dalla soluzione che utilizzi (e da ciò che essa dichiara in termini di accessibilità), è essenziale testarla direttamente sul tuo sito, con i tuoi plugin e il tuo tema attivo. Scopri di più su come eseguire test manuali di accessibilità.
2. Segnala i problemi agli sviluppatori del plugin
Se individui problemi di accessibilità in un plugin — e sei uno sviluppatore web — è possibile risolverli temporaneamente sul tuo sito per garantire la conformità legale. Tuttavia, è altrettanto importante segnalare le problematiche direttamente agli sviluppatori del plugin.
Comunicare i problemi di accessibilità ai developer è fondamentale: permette loro di correggere gli errori alla radice, migliorando l’esperienza di tutti i siti che utilizzano lo stesso strumento.
Risolvere i problemi alla fonte è anche il modo più efficace per evitare che le correzioni vadano perse con i futuri aggiornamenti del plugin.
Puoi segnalare i problemi di accessibilità su GitHub, nei forum di supporto di WordPress, o sul sito web dello sviluppatore.
Se qualcun altro ha già aperto una segnalazione simile, aggiungere un commento per indicare che anche tu riscontri lo stesso problema può aiutare a dare maggiore priorità alla risoluzione.
3. Fai domande (tante) e pensa in modo critico
Quando leggi le pagine di marketing di un plugin WordPress o di qualsiasi altro software che dichiara di essere “accessibile”, mantieni sempre un sano scetticismo.
Ecco alcune domande fondamentali da porre agli sviluppatori per verificare la reale affidabilità delle loro affermazioni in tema di accessibilità:
Come avete testato il plugin per l’accessibilità? Quali strumenti e metodologie avete utilizzato?
Chi ha condotto i test e quali competenze o certificazioni possiede?
Quando è stato effettuato l’ultimo test di accessibilità?
Avete un processo di test continuo per garantire l’accessibilità nel tempo?
È possibile ottenere un Accessibility Conformance Report (VPAT) del prodotto?
Diffida dagli sviluppatori che non si avvalgono di esperti esterni per la verifica dell’accessibilità, a meno che non abbiano specialisti interni qualificati nel loro team.
Se non sono in grado di spiegare come testano o con quale frequenza, questo è un segnale d’allarme evidente.
Non lasciarti convincere da slogan o dichiarazioni vaghe come “prodotto certificato accessibile” senza alcuna informazione su chi abbia effettuato la certificazione.
Quando possibile, chiedi una documentazione ufficiale sotto forma di VPAT (Voluntary Product Accessibility Template) o Accessibility Conformance Report.
Il VPAT è uno standard internazionale per attestare il livello di accessibilità di un software: in ambito pubblico o educativo, è spesso un requisito necessario prima di poter acquistare o utilizzare un prodotto.
4. Correggi o cambia plugin
La conformità legale non è uno scherzo. Se stai utilizzando un banner cookie non accessibile, è fondamentale intervenire rapidamente: correggilo oppure sostituiscilo con una soluzione realmente conforme.
Non sai da dove cominciare? Contattami per scoprire come posso aiutarti a rendere il tuo sito conforme alle normative su privacy e accessibilità.
Disclaimer
Questo articolo è pubblicato da Alessandro De Luca, a scopo puramente informativo e non costituisce consulenza legale.
Le leggi sull’accessibilità e la loro applicazione variano a seconda della giurisdizione e, sebbene questo articolo faccia riferimento a standard generali come le Web Content Accessibility Guidelines (WCAG), non deve essere considerato un riferimento definitivo per determinare la conformità legale in una specifica regione.
Per indicazioni sulle obbligazioni relative all’accessibilità applicabili alla tua organizzazione, consulta un avvocato qualificato. Tutti i problemi riportati sono accurati alla data di pubblicazione e per la versione del plugin testata. Le problematiche possono differire per altre versioni o versioni future del plugin.
Non fornisco alcuna garanzia, espressa o implicita, riguardo all’accuratezza, completezza o affidabilità dei risultati presentati in questo articolo, e non mi assumo alcuna responsabilità per azioni intraprese sulla base di queste informazioni. Per consulenze personalizzate sull’accessibilità o per ricevere supporto esperto sulla tua situazione specifica, puoi contattarmi direttamente.
Tutti i nomi di prodotti, loghi e marchi citati in questo articolo sono marchi registrati dei rispettivi proprietari. L’uso di tali nomi, loghi e marchi ha scopo identificativo e non implica alcun endorsement o affiliazione tra me e i titolari dei marchi.
