Cookie Banner Accessibility: Why Your Vendor's Conformance Claim Doesn't Protect You

Your development team has done the work. The codebase passes an automated scan. A manual audit found no blocking issues. And then a keyboard user lands on your site, presses Tab, and goes nowhere - because the consent banner that loads before anything else is completely inoperable without a mouse.

This is the structural problem with third-party UI components: the component that greets every single visitor is the one least likely to be in your repository, least likely to have been tested by your QA team, and most likely to carry accessibility failures that your own audit never surfaces.

Under the European Accessibility Act, if your product or service uses third-party components, you are still responsible for the accessibility of the final result. A vendor's ACR does not transfer conformance to you - it shows due diligence, but it does not shift liability. Third-party components, SaaS integrations, and embedded services are your accessibility liability. Non-conformant third-party content does not exempt you from EAA obligations.

That is the ownership problem. The rest of this article is about the specific failures it produces, and what to do about them.

---

The Evidence: CMP Platforms and the Accessibility Gap

The consent banner is not a peripheral concern. The EAA, which came into force on 28 June 2025, makes WCAG 2.2 Level AA the enforceable standard for digital services in the EU - including cookie banners. A non-accessible banner can invalidate consent entirely under GDPR, because users who cannot operate the interface cannot meaningfully give or withdraw it.

The practical picture from independent testing is sobering. Independent testing in early 2025 found that not a single cookie consent solution examined met the legal requirements for website accessibility under laws such as the EAA, ADA, or Section 508 - all had accessibility and WCAG failures despite making broad conformance claims. This finding, reported by Secure Privacy, is consistent with a 2025 academic study published at HCII 2025 that investigated the technical and cognitive accessibility of cookie consent banners for people with varying abilities - finding significant gaps across both dimensions.

The implication is not that every CMP is permanently broken. Some vendors have since published updated conformance reports. The implication is that marketing claims of WCAG conformance require independent verification, not trust. Vendor selection requires scrutiny: look for platforms that publish accessibility conformance reports and offer documented ARIA implementation details, rather than relying on marketing claims alone.

---

Five Failure Clusters - and the WCAG Criteria Behind Them

The following table maps the most common consent banner failures to the specific WCAG success criteria they violate, with a 30-second manual test for each.

Keyboard access and focus trapping (SC 2.1.1, 2.1.2)

Every element in the cookie banner must work with a keyboard - users should be able to tab through options, make a choice, and close it. When the banner appears, focus must move to it and trap there until closed. The most common failure is a banner dismissible only by clicking an X in the corner, with no Escape key handling and no programmatic focus move on load. A keyboard user who cannot reach the banner controls cannot dismiss it - and cannot reach the page behind it.

Focus management and visible focus (SC 2.4.3, 2.4.7, 2.4.11)

SC 2.4.11 Focus Not Obscured (Minimum) is a WCAG 2.2 addition that catches a genuinely new failure pattern. WCAG 2.2 added the "Focus Not Obscured" criterion (SC 2.4.11), which means the banner itself must not block the user's ability to see where their keyboard focus is at any moment. To comply, cookie banners must not be made "sticky" using position: fixed or any other method, as this risks covering or obscuring content which has focus applied.

A notification implemented as sticky content, such as a cookie banner, will fail this success criterion if it entirely obscures a component receiving focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using scroll padding so the banner does not overlap other content.

Screen reader semantics (SC 4.1.2, 1.3.1)

A consent banner that renders as a <div> with no role="dialog", no aria-modal="true", and no accessible name is invisible to screen reader users as a distinct context. Toggle switches - the standard UI for per-category consent - are a particular problem: a custom toggle with no aria-checked attribute announces nothing about its current state, violating SC 4.1.2 Name, Role, Value. Background content that remains interactive while the banner is open means a screen reader user can navigate away from the banner entirely without making a consent choice.

Contrast and target size (SC 1.4.3, 1.4.11, 2.5.8)

This is where accessibility law and GDPR dark-pattern law converge on exactly the same design decision. Using different contrast ratios for "Accept" and "Reject" buttons - where the "Accept" button has high contrast while the "Reject" button has low contrast - makes the "Reject" button less visible and harder to notice, and users might unintentionally give consent due to the visual prominence of the "Accept" option.

EDPB Guidelines 05/2020 on Consent explicitly state that consent is not freely given if the user interface steers users towards acceptance. They describe buttons that make acceptance easier or more prominent than rejection as a form of design manipulation incompatible with free consent. EDPB Guidelines 03/2022 on Dark Patterns catalogue specific dark patterns that violate GDPR. The "unequal prominence" pattern - where the accept button is visually dominant and the reject option is minimised - is listed explicitly as illegal.

A "Reject all" link rendered in low-contrast grey text fails SC 1.4.3 (4.5:1 contrast ratio for normal text) and simultaneously constitutes a GDPR dark pattern. Two regulators, one design decision.

SC 2.5.8 Target Size (Minimum), introduced in WCAG 2.2, requires interactive targets to be at least 24×24 CSS pixels. Small toggle switches and text links used as consent controls frequently fail this criterion.

Timing and motion (SC 2.2.1, 2.3.3)

Preference options must be accessible without time limits. No auto-dismissal without user action. A banner that disappears after a few seconds without user interaction does not constitute valid consent under GDPR - and also fails SC 2.2.1 Timing Adjustable. Animated slide-in banners that ignore prefers-reduced-motion fail SC 2.3.3 Animation from Interactions.

---

Beyond Consent: The Other Four Third-Party Surfaces

The consent banner is the most visible third-party accessibility problem, but it is not the only one. Apply the same ownership lens to these common embedded components.

Live chat and chatbot widgets

The chat bubble that floats in the corner of most commercial websites carries its own failure cluster. The launcher must be focusable and reachable by Tab. When the widget opens, focus should move to the message input. On close, focus should return to the launcher. New messages arriving in an open chat window must be announced to screen reader users without stealing focus - the correct pattern is role="log" or role="region" with aria-live="polite" on the transcript container, so new answers announce without stealing focus.

SC 2.4.11 (Focus Not Obscured) applies here too: sticky headers, floating chat widgets, cookie consent banners, and modal overlays are the usual culprits for obscuring focused elements.

Embedded video players

Third-party video players - YouTube embeds, Vimeo, custom players - must provide keyboard-operable controls, captions for pre-recorded audio content (SC 1.2.2), and audio description where visual content carries meaning not conveyed in the audio track (SC 1.2.5). Custom player controls built without accessible names fail SC 4.1.2. If you embed a player via iframe, the iframe requires a descriptive title attribute - every iframe must have a clear, descriptive title or be hidden from assistive technology. Screen readers announce the iframe title when users move focus into it. If the title is missing or generic, users cannot understand what the embedded content is for.

Embedded maps and iframes

Maps embedded via Google Maps or similar services present two consistent failures: the iframe lacks a title attribute, and keyboard users can become trapped inside the map's interactive layer with no way to exit. A non-map alternative (a text address, a link to directions) is the practical mitigation when the map itself cannot be made fully accessible.

Payment and checkout iframes

Cross-origin payment iframes (Stripe, Adyen, Braintree) present a specific challenge: focus management across document boundaries is not straightforward, and error messages generated inside the iframe may not be announced to screen readers in the parent document. Inaccessible checkout flows that prevent screen reader users from completing purchases independently are explicitly cited as an EAA enforcement risk. Test payment flows end-to-end with a screen reader, not just the surrounding page.

---

Governance: Building a Third-Party Accessibility Inventory

The practical starting point is knowing what you have. Most teams cannot name every third-party script that renders UI on their site. A third-party accessibility inventory should capture:

• Every embedded script that renders visible or interactive UI (consent platform, chat widget, video player, review widget, map, payment iframe, analytics that injects UI)
• What it renders - modal, floating widget, inline iframe, injected DOM
• Who owns it - internal team, SaaS vendor, open-source library
• Current conformance evidence - ACR/VPAT against EN 301 549, date of last audit, assistive technologies tested

How to test third-party UI properly

Automated scanners systematically under-report failures inside third-party components, particularly those rendered in shadow DOM or cross-origin iframes. A scanner that cannot read the DOM of a cross-origin iframe will report no issues - not because there are none, but because it cannot see inside.

Manual testing is non-negotiable for these components:

1. Keyboard-only pass - Tab through the entire component without touching the mouse. Can you reach every control? Can you operate it? Can you exit?
2. Screen reader pass - Test with NVDA + Chrome on Windows and VoiceOver + Safari on macOS/iOS. Does the component announce correctly? Are state changes communicated? See our screen reader testing protocol for a structured approach.
3. 200% zoom and 320px reflow - Does the component remain operable at 200% browser zoom? Does it reflow without horizontal scrolling at 320px viewport width (SC 1.4.10)?
4. Reduced motion - Enable prefers-reduced-motion in OS settings. Does animation stop?

What to put in vendor contracts

If you are purchasing a third-party digital product, request that your vendor provides a completed VPAT documenting conformance with EN 301 549, the presumptive standard for EAA compliance. Beyond the VPAT, contracts for UI-rendering components should include:

• An ACR against EN 301 549 (not just WCAG - the EAA's technical standard is EN 301 549)
• A remediation SLA: a defined timeframe within which the vendor must fix reported accessibility failures
• The right to self-host or replace the component if the vendor fails to remediate within the SLA
• A requirement that any custom configuration (colours, layout, copy) be re-tested before deployment - custom changes to default settings may impact the accessibility of the banner and may require separate evaluation

---

The Decision: Self-Host or Accept the Vendor's UI?

Every team using a third-party CMP eventually faces this question. Here is the honest trade-off.

Accepting the vendor's default UI means faster deployment, automatic updates when the vendor remediates issues, and reduced implementation burden. The risk is that you are dependent on the vendor's update cadence, and their conformance claim does not transfer to you. If their banner fails an audit, you fail the audit - regardless of what their marketing page says.

Self-hosting and controlling the consent UI means your team owns the accessibility of the component entirely. You can test it, fix it, and conform it to your own standards. The cost is implementation time, ongoing maintenance, and the need to ensure your consent signal is correctly wired to the CMP's backend. For teams with mature front-end practices and an existing design system, this is often the lower-risk path.

A middle path - using a CMP's API to drive a consent UI you build and own - gives you the vendor's consent logic and storage while keeping the rendered interface in your own codebase and test suite.

A market surveillance authority can act on the accessibility breach while a data protection authority acts on the invalid consent - two regulators, one banner. That dual exposure is the clearest argument for treating the consent UI as a first-class engineering concern, not a vendor configuration task.

The EAA is in force. It treats your cookie banner as part of the service it sits in front of. If that service is in scope - an online shop, a consumer banking app, an e-book platform - the banner must be operable by keyboard, readable by screen readers, and perceivable at sufficient contrast, or you are breaking EU law on two fronts at once.

The vendor's conformance claim does not change that. Ownership does.

---

Related reading: WCAG 2.2 vs 2.1 - what changed · Accessible forms: the developer's fix-first guide · ARIA labels and accessible names · Accessibility conformance reports and VPATs