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.

This post was originally published in February 2025, but was significantly updated following additional testing in September 2025. See change log.

Why Cookie Banner Accessibility Matters

Privacy laws worldwide require websites to provide clear and transparent information about the data they collect from users, as well as 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

Episode 4 of the Accessibility Show with Joe Dolson 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.org, only Cookie Compliance by Hu-manity says nothing about accessibility. Most other popular cookie consent plugins and SaaS offerings promise accessibility, either with a brief sentence or an entire marketing page touting their accessibility. Unfortunately, they don’t always deliver on their promises.

What Cookie Consent Solutions Promise

Complianz Accessibility Statements

Complianz has one million-plus active installs. Complianz’s WordPress.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.”

CookieYes Accessibility Statements

The CookieYes plugin also has one million-plus installs. CookieYes’s WordPress.org plugin page states: “Accessibility: The banner is WCAG/ADA compliant for accessibility.”

This text was added sometime in September 2025. Previously, CookieYes did not state that it was compliant with WCAG and ADA or accessible.

Moove GDPR Cookie Compliance Accessibility Statements

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.

Their WordPress.org plugin page states that the plugin is “Optimized for WCAG & ADA accessibility guidelines.”

Real Cookie Banner Accessibility Statements

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

This knowledge base 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.”

CookieAdmin Accessibility Statements

The CookieAdmin plugin has 100,000+ active installs. CookieAdmin’s WordPress.org plugin page lists the following as a free feature: “ADA, EAA & WCAG Compliant.”

Usercentrics Accessibility Statements

Note: Usercentrics referenced in this post is the version available via a paid subscription on the Usercentrics website, not the free Usercentrics CookieBot WordPress plugin.

Usercentrics has 613,772 active installs according to BuiltWith. Usercentrics has a badge in its website footer that claims it is “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 specify who certified them or, at worst, entirely fabricated because no one actually certified them at all.

Any plugin that claims to be WCAG conformant is using the correct language; however, if a company doesn’t specify how it knows its solutions conform to WCAG, you would be right to question the validity of those statements.

If there’s no information about who conducted 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 is genuinely WCAG-conformant without the need for at least some remediation, and many have critical failures despite claiming WCAG conformance.

In February 2025, the WP Accessibility Day website team tested cookie banners in an effort to find one suitable for use on the conference’s website. Sadly, not a single cookie consent solution we examined met the legal requirements for website accessibility under laws such as the European Accessibility Act, ADA, or Section 508. They all had accessibility and WCAG failures despite making broad claims that they are conformant.

The original version of this post had findings from those February 2025 tests. It has since been updated with further testing.

The plugins listed below were all tested by Alex Stine, a blind accessibility expert, and me on September 24, 2025, during a WordPress Accessibility Meetup. The recording for that meetup can be found here. The recording contains many but not all issues listed below.

Note: This was not a comprehensive accessibility audit, and there may be additional WCAG failures present that are not listed here. Listed issues may not be present in other or future versions of the plugins.

Complianz Accessibility Issues

Version Tested: 7.4.2

Accessibility failures:

• Missing tab focus lock for dialog.
• In the preferences view, nested interactive components (toggle buttons inside the <summary> tag).
• Clicking Accept triggers a focus loss. This should return to the skip link the first time or redirect to the Manage Consent button if that was the trigger for the dialog.
• Manage consent button is missing aria-haspopup and aria-controls.
• Fails 1.4.10 Reflow because content is lost at 400% zoom.

Usability failures/possible issues:

• Links to policies are after the Accept/Deny button and may be missed.
• It might be better to have the manage consent button at the top of the DOM; at the bottom, it is harder for users to find. 
• Alex didn’t expect the “Save Preferences” button to close the modal, only to close the saved content. There was confusion about the meaning of the ‘Accept’ vs. ‘Save’ button labels.

Show/Hide issues from February 2025

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

---

CookieYes Accessibility Issues

Version Tested: 3.3.5

Accessibility failures:

• Focus is not shifted to the banner, and it is loaded above the current focus position (skip link). The banner loads after screen reader focus is already set, and is not announced. This makes it very difficult to find or know it’s there; users have to move backward up the page to find it.
• Is contained in a region landmark instead of a dialog. This isn’t a problem for a screen reader user, but it’s a failure of 1.3.1 Info and Relationships because the visual presentation doesn’t match the accessibility semantics and behavior, and it can cause other issues. If using a region role, the banner shouldn’t overlay other content.
• Missing tab focus lock on the dialog, allowing users to interact with the page without making a selection or closing the modal. This can cause 2.4.11 Focus Not Obscured (Minimum) failures because items behind the modal can receive focus and will not move into view.
• The button labels are insufficient, given that it’s in a region instead of a dialog. The buttons read as “Accept All” without the context of “Accept All Cookies”. The use of a region allows the content to mix with the page content, which means controls need to be more specific.
• The customize button is missing aria-haspopup and aria-controls.
• The accordion buttons don’t read the description if navigating using the tab key they need aria-describedby.
• Clicking Save Preferences returns focus to a “group” and it’s unclear where you are on the page.
• The consent preference button is missing aria-haspopup and aria-controls.
• The “Show more” button in the dialog does not shift focus to newly revealed content. Focus is completely lost when the “Show more” button is removed from the DOM after a click.

Usability failures/possible issues:

• Heading in the banner is an H1. This is not a WCAG failure, but as a best practice, there should only be one H1 on the page.

CookieYes was tested for the first time in September, so there are no issues to compare against from February 2025.

---

Moove GDPR Cookie Compliance Accessibility Issues

Version Tested: 5.0.8

Accessibility failures:

• Does not receive focus or notify screen reader users that a banner is available for accepting or denying cookies. It is located in a complementary landmark at the very bottom of the page, and there is no heading in the banner. For a screen reader user, the discoverability of this banner is “about 10%”, according to Alex.
• Missing tab focus lock, allowing users to interact with the page without making a selection or closing the modal. This allows items behind the banner to receive focus even though they are obscured.
• The Change cookie settings button has aria-haspopup="true", which is the wrong value; it announces as a menu. Value should be dialog.
• Tab controls and panels in the settings dialog are missing all required ARIA attributes.
• Inputs are hidden with display:none so they cannot receive tab focus and are not functional for keyboard users.
• Headings are missing heading markup (paragraphs or spans styled to look like headings).
• Focus is not managed when the dialog is closed.
• Focus indicators in the dialog are missing or insufficient.
• Content in the modal crops or is lost when 200% and 400% zoom is applied.
• Color alone is used to distinguish between default and hover states.

Show/Hide issues from February 2025

I reported these issues in the GDPR Cookie Compliance WordPress support forum. All issues except one remain unresolved as of September 30, 2025.

• The cookie dialog is missing required ARIA attributes.
• Focus indicators in the dialog are missing or insufficient.
• Buttons triggering modals are missing aria-haspopup.
• 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.
• The settings tabs are not programmatically defined as tabs or labeled as such for screen reader users.
• Links to the privacy policy and the GDPR Cookie Compliance website are not keyboard-focusable or clickable without a mouse. – resolved

---

Real Cookie Banner Accessibility Issues

Version Tested: 5.2.1

Accessibility failures:

• Focus does not shift into the banner on initial page load. The cookie banner is placed above the current focus position (skip link) and was loaded after the screen reader focus had already been set. 
• Focus order doesn’t match the visual order. It goes to “Continue without consent,” “Accept All,” then “Set privacy settings individually,” which is out of order with the page.
• No headings for the different sections in the dialog. Alex noted the dialog is “hard to navigate” because of how much text there is, and it’s not broken up very well (lots of divs rather than lists or other semantic containers), and there are no headings.
• Fails 1.4.10 Reflow because sticky elements make it impossible to read the dialog content at 400% zoom.

Usability failures/possible issues:

• The “Skip to consent choices” link doesn’t take the user to the expected place when customizing choices. Alex thought it would go to the customization settings, not the overall controls. Given the amount of text in the banner, he wanted a way to jump directly to those controls.
• Alex noted that having the save button at the top is really annoying for him because it is hard to find, especially on a dialog like this that has so much content. He doesn’t want to have to move through all the controls to configure them and then again in reverse to find the save button.

Show/Hide issues from February 2025

I reported these issues on the Real Cookie Banner WordPress support forum. All issues except one are resolved as of September 30, 2025.

• The dialog is not consistently getting focus on load. – still present
• 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.
• 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.

---

CookieAdmin Accessibility Issues

Version Tested: 1.1.0

Accessibility failures:

• The modal does not receive keyboard focus and is not announced to screen reader users when it opens.
• There is no landmark region at all for the modal; it is at the very bottom of the page, and it is missing all the expected ARIA for dialogs. Alex said the discoverability of this banner is “about 5%,” meaning most blind users will never know it’s there.
• Missing tab focus lock, allowing users to interact with the page without making a selection or closing the modal. This allows items behind the banner to receive focus even though they are obscured.
• Headings are missing heading markup (paragraphs or spans styled to look like headings).
• Their powered by link is missing an accessible name for the image.
• The Customize button is missing aria-haspopup and aria-controls.
• Personalize Your Cookie Preferences modal missing dialog role, accessible name, and ARIA dialog attributes.
• When the Personalize Your Cookie Preferences modal opens, focus goes to a random place in the middle of the modal.
• Close button missing accessible name.
• The paragraph in the middle of the dialog is incorrectly given a role of dialog.
• Show more button doesn’t shift focus to newly revealed text.
• Personalize Your Cookie Preferences modal missing tab focus lock.
• Accordions for different cookie types are missing buttons to open and close them – it’s a <span> with an icon in it; no accessible name, not tab focusable, and missing aria-expanded.
• Cookie information is confusing and missing meaningful structure – it’s all just a div. This would be better as a table.
• Inputs are hidden with display:none; they cannot receive tab focus and are not keyboard functional.
• Inputs don’t have a label.
• Closing the modal results in a total loss of focus.
• Fails Reflow because sticky elements make it impossible to read the dialog content at 400% zoom.

CookieAdmin was tested for the first time in September, so there are no issues to compare against from February 2025.

---

Usercentrics Accessibility Issues

Version Tested: unknown. This is not a WordPress plugin, so there’s no known version number. Issues are accurate as of September 30, 2025.

Accessibility failures:

• Essential button is disabled and also hidden with aria-hidden so screen reader users can’t find it or even know that there are some essential cookies being set.
• “View Service Details” buttons are missing unique labels.
• “View Service Details” buttons are missing aria-haspopup and aria-controls.
• “View Service Details” modals are missing dialog role, accessible name, and ARIA dialog attributes.
• Save settings button causes focus loss.
• The “Privacy Settings” button that opens and closes the dialog is in a div with a role of dialog, even though it’s not a dialog. The accessible name for the div is also “privacy settings” which is repetitive and confusing.
• Closing the dialog causes a loss of focus.
• Elements with role="button" cannot be triggered with the spacebar.

Usability failures/possible issues:

• Details button seemed ambiguous – Alex wanted to see a better label “Details about what?”
• Every accordion has a region role – this is excessively noisy for screen reader users and not what is expected of accordions. In general, Alex’s feedback was that they were overusing ARIA.
• Close buttons all say “Close Layer” which is unusual/confusing. Normally this would be “Close dialog”, “close modal”, or just “close”.
• This is very close to failing Reflow due to stickly components, the gradient overlay, and some elements being slightly cutoff at 400% zoom. It’s usable but could be better.

Show/Hide issues from February 2025

These issues were reported to Usercentrics via their plugin support forum. Some are resolved, but others are still present.

Still present:

• 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.
• Links open in a new tab with no disclosure.
• Accessible name on the close button is “close layer” which is likely to be confusing.
• 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.
• 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.
• 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.

Resolved:

• 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.”
• There’s a lot of use of tabindex=0, making some things are focusable that should not be.
• 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.
• 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.
• 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.

---

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.

Instagram

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

Email(Required)

Name

First Last

Subscribe Consent(Required)

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

Why are WordPress Cookie Banners so Bad at Accessibility?

One of the key observations from our testing was the extensive use of ARIA in attempts to enhance 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.

Are these tools “Lying”?

After testing these tools (some twice over a six-month period) and receiving feedback from plugin developers, I think it is worth clarifying my statement that your cookie banner solution is “lying” about accessibility.

At its simplest, “lying” is knowingly making a false statement. If a company knows their cookie banner is not fully WCAG conformant or knows they haven’t tested it for every success criterion, but markets it as “WCAG compliant,” that crosses into lying.

But not every misleading claim is intentional. Some teams may lack expertise, rely too heavily on automated testing, or assume that being “mostly accessible” is good enough. In these cases, their statements are better described as misrepresentations rather than deliberate lies.

The problem is that “mostly accessible” is insufficient in many legal or ethical contexts. When a plugin advertises “WCAG compliance”, “ADA accessible”, or “certified accessible”, those statements carry heavy expectations. If what’s advertised is overselling the actual implementation, there can be real consequences for website users and owners.

I don’t have access to the internal conversations behind these tools, and I don’t know their intent. Likely, some are knowingly lying to attract customers, while others have good intentions but lack the necessary expertise and haven’t invested in hiring an accessibility specialist to test their products.

Regardless of which is true, it’s concerning to see such a mismatch between marketing language and functionality. As someone who has spoken with many website owners who were on the receiving end of a lawsuit or government action after believing they had built their website using accessible tools, I firmly believe that this mismatch is unacceptable.

Ultimately, whether we call it lying or misrepresentation or misunderstanding, the result is the same: people with disabilities are excluded, and website owners are put at risk. Accessibility is not a marketing checkbox or a feature to be claimed without proof—it’s a commitment that requires rigorous testing, transparency, and accountability.

If cookie banner plugins (or any WordPress plugins) claim to be WCAG compliant, they need to support those claims with real evidence: documentation of testing, clear disclosures of limitations, and ideally validation from accessibility professionals and end-users with disabilities.

What should you do?

If you’re using one of these plugins or a different cookie plugin not listed here, you may wonder what steps to take to ensure your cookie notice complies with privacy and accessibility laws. Here are our recommendations:

1. Manually Test Your Cookie Solution for Accessibility

It’s important to always manually 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.

Disclaimer

This article is published by Equalize Digital, Inc. for informational purposes only and does not constitute legal advice. Accessibility laws and enforcement vary by jurisdiction, and while this report references general standards such as the Web Content Accessibility Guidelines (WCAG), it should not be relied upon to determine legal compliance in any specific region. For advice on accessibility compliance obligations applicable to your organization, please consult a qualified attorney.

All listed issues are accurate as of the publication date and for the tested plugin version. Issues may be different for other or future plugin versions. Equalize Digital, Inc. disclaims any warranties, express or implied, regarding the accuracy, completeness, or reliability of the findings in this article, and assumes no liability for actions taken based on this information. For personalized accessibility consulting and expert advice about your specific situation, please contact us.

All product names, logos, and brands referenced in this article are trademarks of their respective owners. Use of these names, logos, and brands is for identification purposes only and does not imply endorsement or affiliation between Equalize Digital, Inc. and respective trademark holders.