A cookie banner has two jobs: control tracking according to the visitor’s choice, and be usable by every visitor, including people who navigate by keyboard or screen reader. Most banners fail at least one of those jobs, which is why what you test after installation matters more than which tool you install.
The banner is where every privacy law meets your visitors. Opt-in consent, opt-outs, and withdrawal all happen here, which makes this page the implementation companion to website privacy compliance.
| Key Point | What It Means for You |
|---|---|
| Functional: block first | Non-essential tracking is prevented from loading until the visitor chooses, wherever opt-in applies. |
| Functional: honor the choice | Reject, opt-out, and withdrawal actually stop tracking, verified in the network, not assumed from the interface. |
| Accessible: operable | Fully usable by keyboard and screen reader, with managed focus, per WCAG 2.1 AA. |
| Accessible: perceivable | Sufficient contrast, adequate target sizes, and readable at high zoom, per WCAG 2.1 AA and WCAG 2.2 AA. |
| Tested as rendered | Conformance and blocking are verified on your site, in your theme, not taken from a vendor demo. |
What must a cookie banner do functionally?
Functionally, the banner is a gate between your visitors and your tracking. The requirements come from the privacy laws, and they reduce to four behaviors:
- Where opt-in applies, block cookies, pixels, session replay, and chat scripts until the visitor agrees
- Present honest choices: reject as available as accept, granular purposes, no pre-selected boxes
- When the visitor rejects, opts out, or withdraws, stop the associated tracking
- Record each choice so consent and opt-outs can be proven later
Which behaviors apply to which visitors depends on the law: opt-in for the EU and UK under the GDPR, opt-in blocking as the defensive posture for California under CIPA, and a working opt-out with Global Privacy Control honoring under the CCPA. One banner has to serve all of them correctly, to the right visitors.
What makes a cookie banner accessible?
An accessible banner is one every visitor can perceive, operate, and understand. The measuring stick is WCAG conformance at 2.1 AA, with WCAG 2.2 AA adding criteria that consent dialogs trip constantly. Four areas decide most outcomes.
Keyboard operability
Every part of the banner must work with a keyboard alone: reaching it, moving between accept, reject, and settings, operating toggles in the preference center, and closing it. Two failures dominate. The banner is unreachable, sitting outside the tab order entirely. Or it becomes a trap, where focus enters and cannot leave, locking a keyboard user out of the entire page behind it.
Screen reader announcement and semantics
When the banner appears, a screen reader user needs to know it exists, what it asks, and what the controls do. That requires dialog semantics, an accessible name for the dialog and every control, and correct roles and states on toggles. A banner that appears silently is a decision the visitor never knew they were asked to make. Tracking that proceeds on their silence was never consented to.
Focus management
Focus should move into the banner when it opens, stay within it while it blocks the page, remain visible at every step, and return to a sensible place when it closes. WCAG 2.2 adds that the focused control cannot be hidden behind other interface elements, which sticky banners violate regularly.
Contrast, target size, and zoom
Banner text needs contrast of at least 4.5:1, and control boundaries at least 3:1, which brand-colored consent buttons frequently miss. WCAG 2.2 AA expects interactive targets of at least 24 by 24 pixels, and cookie banners full of small toggles and tight links are exactly where that bites. Content must also survive 400 percent zoom without loss, where fixed-position banners often break.
Why is an inaccessible cookie banner a legal risk?
Two exposures run at once, through the same interface.
First, accessibility law. The banner is often the first interactive element on every page of your site. Under the ADA’s application to websites, a banner that blocks content while being inoperable by keyboard or screen reader is a barrier at the front door, and it is among the first things any accessibility review will find.
Second, consent validity. Every privacy framework assumes the visitor could actually use the consent interface. Consent that a visitor could not perceive or operate is not informed and not unambiguous under the GDPR. A consent defense to a CIPA claim is weakened for sessions where the banner never announced itself. An opt-out that a disabled Californian cannot reach fails the CCPA’s promise that the right can be exercised. Conformance claims across the consent industry vary widely in how they are substantiated, which is exactly why the only claim that matters is what your banner does on your site.
Why must you test the banner after installing it?
Because installation is where the vendor’s claim ends and your site’s reality begins. The recurring failure modes are simple to state:
- Scripts outside the banner’s reach. Tags hardcoded into the theme or template never receive the consent decision and fire regardless of the visitor’s choice
- Signals mistaken for blocking. Some integrations send tags a denied signal rather than preventing them from loading. The tag still loads, and some still transmit
- Tags loading tags. A permitted script injects another script the consent tool never identified, and tracking arrives through the side door
- The race at page load. Tracking fires in the moments before the consent tool initializes, before any choice was possible
- The theme breaks the accessibility. A banner that conformed in the vendor demo inherits your site’s styles, z-index stack, and customizations. Focus outlines disappear, contrast shifts, and the tested product is no longer the rendered product
Testing means opening a clean browser and watching the network: what loads before any interaction, what loads after reject, what stops after withdrawal. It also means completing the banner with a keyboard alone and with a screen reader, on your site. Recorded, dated results of that testing are evidence you can produce if a demand letter or regulator ever asks. Assumptions are not.
How do the app and services get the banner right?
The app
Our consent app is available for Shopify, WordPress, and as a general script for all other sites. Functionally, it blocks non-essential tracking until the visitor chooses, serves opt-in and opt-out behavior to the right regions, honors Global Privacy Control, and records every choice. On accessibility, the banner and preference center are built to conform with WCAG 2.1 AA and WCAG 2.2 AA: keyboard operable end to end, announced with proper dialog semantics, visible managed focus, conforming contrast, and adequate target sizes. One scope note we state plainly: conformance covers the banner and app interface. It does not make the rest of a website conformant, and claims broader than that should raise questions about any consent product.
The services
We implement the banner on your site, then conduct manual verification testing of both jobs as rendered in your theme: network-level testing that rejection, opt-out, and withdrawal genuinely stop tracking, and accessibility testing of the banner by keyboard and screen reader on your actual pages. Both are recorded, dated, and preserved with the configuration tested. We also provide privacy policy language documenting your consent practices and guidance for retesting as your site and tags change.
Frequently asked questions
Are cookie banners required to be accessible?
Yes. The banner is part of your website, so accessibility obligations apply to it fully. Its position in front of all content makes it one of the most consequential interfaces on the site.
Which WCAG version applies to cookie banners?
Test against WCAG 2.1 AA as the baseline and WCAG 2.2 AA for current best practice. WCAG 2.2 adds criteria on focus visibility and target size that consent dialogs frequently fail.
Can I rely on a vendor’s claim that its banner is WCAG conformant?
Treat it as a starting point, not a result. Conformance was assessed on a default configuration, and your theme, styling, and setup change the rendered outcome. Testing on your site is what confirms it.
Does an accessible banner also mean tracking actually stops?
No. Accessibility and blocking are separate jobs, and each needs its own testing. A perfectly operable banner can still sit in front of tracking that fires anyway.
What is the fastest way to check my current banner?
Tab to it with a keyboard and try to complete every choice, then watch the network tab in a clean browser while you reject. If either test surprises you, a full review is warranted.
Where to start
- Complete your current banner by keyboard alone and with a screen reader, on your live site
- Watch the network in a clean browser: before interaction, after reject, after withdrawal
- Fix the reach problems first: hardcoded tags, signal-only integrations, and load-order races
- Bring the banner to WCAG 2.1 AA and WCAG 2.2 AA as rendered, not as demoed
- Record the testing, date it, preserve it, and retest when the theme or tags change
