WordPress Cookie Banner Accessibility Lies

This blog post has an edgy title, WordPress Cookie Banner Accessibility Lies, but I honestly can’t think of another succinct phrase that perfectly describes this post. The truth is, I’m frustrated by WordPress plugins and SaaSes that claim to be accessible when they’re not. For cookie banners, which are required by law in many parts of the world, false accessibility claims can put the website owner on the wrong side of not just accessibility laws but privacy laws, too.

Why Cookie Banner Accessibility Matters

Privacy laws worldwide require websites to provide clear and transparent information about the data they collect from users and a way for users to consent to or decline tracking.

Example Cookie Notice Laws

European Union: GDPR & ePrivacy Directive

• General Data Protection Regulation (GDPR) (2018): Requires websites to obtain explicit, informed, and revocable consent before storing non-essential cookies.
• ePrivacy Directive (Cookie Law) (2002, updated in 2009): Mandates that users must be informed about cookies and given a choice to accept or reject them.

United Kingdom: UK GDPR & PECR

• UK GDPR (2021, post-Brexit version of GDPR): Follows the same principles as the EU GDPR.
• Privacy and Electronic Communications Regulations (PECR): Requires clear and informed consent before placing cookies on user devices.

United States: State-Level Privacy Laws

While there is no federal law mandating cookie banners in the U.S., several state laws require transparency about data collection. U.S. states typically require businesses to disclose if they collect user data and provide an opt-out option for selling/sharing personal information (not explicit consent like GDPR).

Example state laws include:

• California Consumer Privacy Act (CCPA) and CPRA (2023 update)
• Colorado Privacy Act (CPA)
• Connecticut Data Privacy Act (DPA)
• Utah Consumer Privacy Act (UCPA)
• Virginia Consumer Data Protection Act (CDPA)

Canada: PIPEDA

The Personal Information Protection and Electronic Documents Act (PIPEDA) requires obtaining meaningful consent for collecting personal data, which can include cookies.

Privacy Laws Apply to All Users

If you’re required by law to notify users of the cookies on your website, then that notification needs to be available to all users — not just some users, or “typical” users who can see and use a mouse.

If a cookie banner is not readable by screen readers, lacks keyboard functionality, or has poor contrast, users with disabilities may be unable to provide valid consent, putting businesses at risk of non-compliance and potential fines.

To comply with privacy laws worldwide, your website’s cookie banner must be accessible to people with disabilities.

How Accessible is Your Cookie Banner?

My friend Joe Dolson hosts a monthly accessibility podcast with Nathan Wrigley of WP Builds. In each episode, Joe looks at the accessibility of one specific component on several websites from the WordPress Showcase and talks about where they have gotten things wrong. It’s a fascinating look behind the scenes and a great learning opportunity to hear about specific accessibility expectations component by component.

Cookie Banner Accessibility in the WordPress Showcase

Last week, episode 4 of the Accessibility Show with Joe Dolson came out, and it was all about cookie banners. In this episode, Joe shares problems with three different cookie banners from three different cookie banner plugins. They all fail basic accessibility testing, and one can’t even be configured with a mouse!

After watching Joe discuss the issues in these banners, you might be wondering how your cookie notice stacks up.

Or, maybe you’re feeling confident that your cookie banner complies with privacy and accessibility laws because you’ve already considered that and thoughtfully chosen a banner that promised accessibility.

Well, I hate to rain on your parade, but…

Your Cookie Banner Solution is Lying About Accessibility

Of the most installed cookie plugins on WordPress dot org, only CookieYes and Cookie Compliance by Hu-manity say nothing about accessibility. Most other popular cookie consent plugins and SaaS offerings promise accessibility, either with a short sentence or entire marketing pages touting their accessibility. Unfortunately, they don’t always deliver on their promises.

What Cookie Consent Solutions Promise

Complianz

Complianz has 1+ million plus active installs. Complianz’s WordPress dot org plugin page, states that their cookie consent notice is “WCAG Level AA and ADA Compliant” and that “Cookie Banners and Legal Documents conform to WCAG 2.1 AA Accessibility Guidelines and ADA Compliance.”

Moove GDPR Cookie Compliance

The GDPR Cookie Compliance plugin has 300,000 active installs. On their plugin website, there’s a list of features with checkmarks instead of bullet points. One of the features is “WCAG & ADA accessibility”. There’s no other information about accessibility for the GDPR Cookie Compliance plugin on the site.

Real Cookie Banner

The Real Cookie Banner plugin by DevOwl has 100,000+ active installs. Their WordPress dot org plugin page promises accessibility, and there’s an article in their knowledge base discussing the accessibility of Real Cookie Banner.

This knowledgebase article states, “Real Cookie Banner is accessible as of version 3.10.” Continuing on, it says,

“we have brought Real Cookie Banner in line with the renowned standard WCAG 2.2 in terms of perceptibility, usability, comprehensibility and robustness, making it, in our opinion, accessible according to the European accessibility act.”

Usercentrics

Usercentrics has 100,000+ active installs via their plugin and likely many more via a partnership with privacy policy company Termagedon. Usercentrics has a badge in their website footer that claims they are “WCAG 2.1 Certified Web Content Accessibility Guidelines”. The badge links to a web page about the accessibility of Usercentrics that includes claims like:

“Web Content Accessibility Guidelines (WCAG) certification is considered the gold standard for web accessibility.”

and

All layers of the Usercentrics cookie banner for all of our plans have been tested against WCAG 2.1 AA compliance requirements and have passed.

If I were a website owner or developer who wanted to do the right thing, I’d look for a cookie plugin that stated it was accessible.

Finding one certified by the Web Content Accessibility Guidelines sounds even better. Of course, I would pick that one.

Except…

There’s no such thing as “WCAG certification”.

Web Content Accessibility Guidelines (WCAG) are a set of internationally recognized standards for measuring the accessibility of websites, software, and digital content. These standards are developed by organizations and volunteers from around the world through the World Wide Web Consortium (W3C).

The W3C develops standards. It does not “certify” websites or software for accessibility.

That badge on the Usercentrics website is, at best, misleading because it doesn’t say who certified them or, at worst, entirely made up because no one actually certified them at all.

All other plugins state that they’re WCAG conformant (the correct language), but they don’t say how they know their solutions conform to WCAG. There’s zero information about who did their accessibility testing, what tools were used, and whether people with disabilities were included in the testing. This is a giant red flag.

The Truth About WordPress Cookie Banner Accessibility

The truth about WordPress cookie banner accessibility is that I have not found one that works well and is genuinely WCAG-conformant without the need for remediation.

Recently, the WP Accessibility Day website team was testing cookie banners in hopes that we could find one for use on the conference’s website. Sadly, there was not a single cookie consent solution that we looked at that met the legal requirements for website accessibility under laws like the European Accessibility Act, ADA, or Section 508.

Here’s what we found:

Complianz Accessibility Issues

Complianz seemed ok in many respects, but isn’t without issues. Joe opened some issues on Complianz’s GitHub repo for the more serious issues:

• Focus lost when cookie consent banner activated
• Focus lost when choosing ‘View Preferences’
• Interactive elements should not contain other interactive elements
• Label elements should not be keyboard focusable
• Cookie banner checkbox labels are hidden from screen reader users

Moove GDPR Cookie Compliance Accessibility Issues

Our Accessibility Specialist, Maria, recently audited Moove GDPR Cookie Compliance for one of our accessibility remediation customers. While auditing that solution, she found the following issues:

• The cookie dialog is missing required ARIA attributes.
• Focus indicators in the dialog are missing or insufficient.
• Buttons triggering modals are missing aria-haspopup="true".
• Content in the modal crops or is lost when 200% zoom is applied.
• When users navigate the settings tabs, an automatic and unexpected change of context occurs, which can disorient the user and disrupt their workflow.
• The toggle buttons are not keyboard-focusable or clickable without a mouse. 
• Content that appears visually on the screen when toggles are interacted with is not announced by the screen reader.
• Links to the privacy policy and the GDPR Cookie Compliance website are not keyboard-focusable or clickable without a mouse.
• The settings tabs are not programmatically defined as tabs or labeled as such for screen reader users.

I reported these issues in the GDPR Cookie Compliance WordPress support forum.

Real Cookie Banner Accessibility Issues

Real Cookie Banner also seemed like a possibility initially but it still has some deal breakers that need to be fixed for actual WCAG conformance. I reported these issues on the Real Cookie Banner WordPress support forum:

• The dialog is not consistently getting focus on load.
• Modal heading should be an H2 instead of an H3.
• The <dialog> tag needs aria-modal="true" added to it.
• Show service information “links” (and any others) that expand hidden content need to be buttons. You can correct this by adding role="button" to them and adding support for space bar triggering.
• Show service information buttons (currently coded as <a>) should have unique names.
• Hide the middots from screen readers with aria-hidden="true" or by displaying them via CSS (better).
• All links that have been made buttons with role=”button” need to have space bar handlers added so they can be triggered with the spacebar.
• When the “underline” style is set for links, the underline should disappear on hover so color alone is not being used to indicate the hover state.
• There’s a focus order issue after expanding the individual settings options. This is because the link to configure individual settings is removed from the page when clicked. Removing an element from the DOM causes the keyboard to lose focus. The individual settings button should stay visible in the modal, and all the newly added content should be introduced after it (I.e., it should function like an accordion).
• Consent choices checkboxes read the label three times because they’re over-engineered.

Usercentrics Accessibility Issues

Usercentrics, the plugin with the flashiest claims about accessibility, was also not WCAG conformant. Both Joe and I tested it. Here are the issues that we identified:

• The dialog is unlabelled which results in the screen reader reading the content when it opens instead of just a name. Screen reader users hear “Privacy Settings and 2 more items and 6 more items and 7 more items. Dialog.”
• The “checkboxes” aren’t checkboxes at all; they’re buttons with role="switch" and aria-checked attributes. They use aria-labelledby to use the associated label element for labeling, but the label isn’t clickable because…it’s a button, not a checkbox.
• There’s a lot of use of tabindex=0, making some things are focusable that should not be.
• Links open in a new tab with no disclosure.
• Buttons have an aria-label that’s a duplicate of contained content; that’s probably not a problem in most cases, though it could lead to a label in name violation.
• The form layout breaks down significantly at 200% zoom. The region scrolls so that the controls can become visible again, but it’s difficult to interact with.
• Accessible name on the close button is “close layer” which is likely to be confusing.
• Labels should be clickable for the toggles.
• For the toggles or buttons that are on their own, they need to be bigger. Target Size Minimum requires at least 24×24 pixels. The info buttons and toggles in the categories all fail this.
• Toggles can be turned off or on with the space bar when they first receive keyboard focus, but after hitting the space bar once, hitting the spacebar again doesn’t undo the action, it scrolls the page behind the dialog.  You have to tab away and then tab back to be able to trigger it with the spacebar again.
• After you toggle the settings with the space bar or the return key, if you click tab to try and go to the next switch or link, focus reverts to the Privacy Settings heading and you have to tab back through the components to get back to where you were.
• The Usercentrics link doesn’t have anything to identify it as a link. (I’d hide this if I used it, but as it is, that would be an accessibility issue.)
• When you click an info button in the categories, it shifts to the services tab and visually scrolls to the service you selected, but it doesn’t set keyboard focus there, so a screen reader starts reading at the top of the services tab panel, not on the service that someone wanted more information on.
• After you close the dialog, it sounds like it puts you at the top of the page, but it doesn’t. The next tab stop takes you to the floating button for triggering the dialog and then the tab stop after that takes you to the browser address bar. Basically, that button is the last thing in the DOM, and you bypass the entire website.

These issues have been reported to Usercentrics.

Article continued below.

Stay on top of web accessibility news and best practices.

Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.

utm_campaign

utm_medium

utm_source

utm_term

Email(Required)

Name

First Last

Subscribe Consent(Required)

I opt-in to receive emails from Equalize Digital and have read the privacy policy.(Required)

Email

This field is for validation purposes and should be left unchanged.

Why are WordPress Cookie Banners so Bad at Accessibility?

One of the things that we observed in all of our testing was lots of use of ARIA in attempts to improve accessibility. I’m not publishing this blog post to say that the developers of these plugins haven’t tried. In fact, I can tell several of them have put effort into trying to fix accessibility problems already based on their use of role="button" alone.

So why do so many cookie banner plugins have accessibility issues if the developers have put effort? The reason is that it’s always more work and more challenging to get accessibility right after the fact. The best time to build accessibility into your product is at the beginning, and the best way to do it is with semantic components.

It’s clear from the HTML that these plugins did not start with accessibility in mind. They didn’t, for example, use <button> tags initially, so now they rely heavily on ARIA and JavaScript to provide button semantics and functionality.

This doesn’t mean they can’t be accessible, but it does mean that more work needs to be put in, and everything needs to be thoroughly tested.

What Should You Do?

If you’re using one of these plugins or a different cookie plugin not listed here, you may wonder what you should do next to make your cookie notice compliant with privacy and accessibility laws. Here are our recommendations:

1. Manually Test Your Cookie Solution for Accessibility

It’s important always manually to test your website components for accessibility. Automated tools like Accessibility Checker speed up your testing process, but won’t be able to find a <div> that should be an <input>, interactions that cause a loss of keyboard focus, or strangely labeled elements.

Turn off your mouse, turn on a screen reader, and use your cookie notice with only your keyboard. Make sure you can hear all the information in the notice, reach all interactive elements, and consent or decline.

No matter which cookie consent solution you use (and what they say about accessibility), you must test the solution on your website with your plugins and theme. Learn more about manual accessibility testing.

2. Report Issues to the Plugin Developer

If you identify issues in a plugin and are (or you have access to) a web developer, it’s easy to patch them on your own website. Even if you first patch issues on your website to ensure it’s legally compliant, it’s also important to report the issues to the plugin developer.

Reporting accessibility issues to the developer is essential so that they can fix the problems for all websites using their plugin. Fixing issues at the source is also the best way to ensure that the fix will be long-lasting and not something you’ll have to rework after a future plugin update.

You can report accessibility issues on GitHub, in the WordPress support forums, or on the developer’s website. If someone else has already reported the issue, adding a comment that you need the same fix can help move the issue up the developer’s priority list.

3. Ask Lots of Questions & Think Critically

When you’re viewing the marketing page for a WordPress plugin or other software product that claims accessibility, be very skeptical.

Here are questions you should ask WordPress plugin developers to see if their accessibility claims are truthful:

1. How did you test the plugin for accessibility? What tools and techniques did you use?
2. Who did the accessibility testing, and what are their credentials?
3. When was the testing last completed?
4. What is your process for ongoing accessibility testing?
5. Can I get an Accessibility Conformance Report (a VPAT) for the product?

Be skeptical of plugin developers who have not brought in outside experts to verify accessibility unless you know they have trained accessibility specialists on their in-house team. It is a big red flag if they can’t tell you how they accessibility test or how frequently.

Don’t fall for marketing lingo or promises of a solution being “certified” without any information about who is doing the certifying.

Consider asking for documented proof of accessibility in the form of a VPAT or Accessibility Conformance Report. A VPAT is an internationally agreed-upon format for documenting software accessibility. Collecting these from vendors is sometimes required for government or educational websites before they can purchase software.

4. Fix it or Switch it

Legal compliance is no joke. If you’re using an inaccessible cookie banner, you’ll want to fix it or switch it quickly. Not sure where to start? Contact us to learn how we can help.