Your cookie banner vendor has a VPAT/ACR showing full WCAG 2.1 AA or WCAG 2.2 AA conformance. That is exactly what you want to see when you’re about to buy a cookie banner.
If the report is accurate and up to date (and conducted by a reputable accessibility company), the cookie banner itself is in good shape.
But a looming potential problem that gets overlooked is will the cookie banner, as it’s implemented on your website, be WCAG conformant?
There are two key areas we need to look at:
- the cookie banner’s accessibility itself
- the accessibility of your site after implementation
Consent banners are one of the most common sources of accessibility issues we find, and they sit on every page of the site, usually as the first thing a visitor encounters. If the banner isn’t accessible, your site isn’t WCAG 2.1 AA (or 2.2 AA) conformant, and no VPAT/ACR from a vendor changes that.
Why the ACR Doesn’t Cover You
An ACR is a claim about a product, not about an installation. Several things happen between the vendor’s test and your live site.
- Two interfaces, not one. The banner is the first interface. The preferences window (where visitors toggle categories) is the second. Both need to work with a keyboard, both need correct focus management, and both need to be announced properly by screen readers. Vendors sometimes test the banner and treat the preferences window as an afterthought.
- Focus management. When the banner appears, does focus move to it? When it closes, does focus return to a sensible place? When the preferences window opens, is focus trapped inside it so keyboard users don’t tab into the page behind it? These behaviors depend on how the banner is loaded and what else is on the page.
- Screen reader announcements. Does the banner announce itself as a dialog with a name? Are the category toggles announced with their state (on or off)? Is the “reject” option exposed as a real button and not a styled link or div?
- Popup collisions. Newsletter signups, chat widgets, promotional overlays, and exit-intent popups all compete with the banner. A keyboard user can get trapped between two overlays, or a screen reader user can have the banner announced on top of a chat prompt. No vendor tests this because they don’t know what else is on your site.
- Customization. Almost everyone changes something. Button colors that drop below contrast requirements. The reject option demoted to a small text link. The banner repositioned in a way that overlaps content at 200% zoom. Every one of those changes can break the conformance the ACR described.
The vendor tested a product. You installed an implementation. They are not the same thing.
How to Test It
Test on the live site, with the real theme and every third-party app active. The main checks:
- Keyboard only. Load the page, press Tab. You should land in the banner. Tab through every control, including the preferences window. Nothing should be skipped, nothing should be unreachable, and Escape should behave predictably.
- Focus visibility. At every Tab stop, you should be able to see where you are.
- Screen reader. Use NVDA or JAWS on Windows, VoiceOver on Mac. The banner should be announced when it appears. Every button and toggle should have a name and, where relevant, a state.
- Contrast and zoom. Check text and button contrast after your customizations. Zoom to 200% and 400% and confirm the banner doesn’t cover content or lose controls.
- Reject and reopen. Reject all, then find the “cookie preferences” link and reopen the window. Both paths need to work by keyboard.
- Collision test. Trigger every other popup on the site with the banner open and repeat the keyboard and screen reader checks.
How We Can Help
You do not need to use our upcoming consent app for us to test your banner. Whatever you’ve installed, we can perform the testing:
- As part of a full audit. Your consent banner and preferences window are tested and included in your audit report with the rest of the site.
- Banner only. If you just want to confirm the banner and its implementation are accessible, we can test that on its own and give you the findings and fixes.
- With our app. When you use our consent app, accessibility testing on your finished site is part of the implementation service, not an add-on.
The ACR is a starting point. The test on your site is the answer. Contact us and we’ll get it scheduled.
