• Resolved Amber Hinds

    (@alh0319)


    Hello,

    Your website claims that the cookie consent solution is “WCAG 2.1 Certified” and states that “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.” The plugin is not WCAG conformant or accessible.

    Here are a list of issues that I found in a short 20 minute accessibility audit:

    • 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 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.

    Can you please correct these issues so the plugin can be accessible as promised on your website?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support Hanna

    (@hannausercentrics)

    Hi @alh0319,

    Thank you for reaching out and sharing your detailed insights on WCAG standards — we truly appreciate your feedback!

    I’d like to clarify that the article you’re referring to is actually about our other product, Usercentrics WEB CMP. The issue you mentioned isn’t specific to the WordPress plugin. While Cookiebot has never been fully WCAG compliant, we’ve always been committed to making our solution as accessible as possible, even though we haven’t obtained official certification.

    I’ve shared your feedback with our development team so they can review and explore potential improvements. While I can’t provide a timeline for when any updates might go live, please know that we take accessibility seriously and are always looking for ways to enhance our product.

    Thanks again for your input — it’s incredibly valuable to us!
    If you have any other questions or suggestions, feel free to reach out.

    Thread Starter Amber Hinds

    (@alh0319)

    Just to clarify for your dev team, I tested this on a website that was running Usercentrics — I didn’t realize it was different from this plugin.

    This is a screenshot of the cookie notice that I tested and where I found all the issues:

    The link on this notice says “Powered by Usercentrics Consent Management” and goes to a page on the Usercentrics website.

    Apologies that I didn’t realize that this cooke notice banner above is not coming from this plugin. But to make sure the issues get corrected, please note in your system that the WCAG failures I found were indeed with Usercentrics and not with cookiebot.

    Out of curiosity, why is your team not making this plugin accessible?

    Plugin Support Hanna

    (@hannausercentrics)

    Hi @alh0319 ,

    Thank you for the clarification! I appreciate you taking the time to test and report these issues.

    I’ve passed this information along to our development team to ensure the feedback is directed correctly. Since the WCAG concerns you identified are related to Usercentrics and not this plugin, we’ll make sure the right team is aware of your findings.

    Regarding accessibility, we are continuously working to improve our solutions and ensure compliance with best practices. While this plugin is designed with accessibility in mind, we are always looking for ways to enhance it further. Your feedback is valuable in helping us prioritize improvements, and I’ll make sure to share it with the team.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Many Accessibility Issues in Plugin’ is closed to new replies.