On most websites the cookie banner is the first element visitors interact with, often before a single piece of content becomes visible. This consent dialog is regularly overlooked in accessibility reviews, even though it is technically an interactive module with buttons, checkboxes and focus behavior. In the WebAIM Million report 2025, 94.8 percent (WebAIM Million 2025) of the home pages examined had detectable WCAG 2 failures, many of them in exactly these kinds of controls. As soon as access to the site is tied to consent, the banner becomes the gatekeeper of the entire service. This article shows where consent banners fail against WCAG 2.2 AA and how a WCAG 2.2 audit uncovers the typical errors before market surveillance flags them.
When a Cookie Banner Falls Under the BFSG
The German Accessibility Strengthening Act (BFSG) requires the digital service itself to be accessible, that is, the website, the online shop or the app. The consent dialog is part of this user interface and cannot be separated from it. Technically, the BFSG builds on the harmonized standard EN 301 549, which references the WCAG success criteria for web content (BFSG). A banner that violates the WCAG criteria is therefore a barrier within an otherwise tested page. How the requirements of the BFSG look in detail and why the EN 301 549 standard behind the BFSG provides the yardstick, we cover in separate articles.
The scope becomes especially clear when access is tied to consent. With a cookie wall or a paid ad-free model along the lines of consent or pay, no one gets past the dialog. Anyone who cannot operate the banner with a keyboard or a screen reader is excluded from the entire service, not just from an add-on feature. An overlooked detail thus turns into a hard access barrier that weighs heavily in an inspection.
The Yardstick Is Fixed
The Typical Barriers in the Consent Banner
Consent banners rarely fail because of a single gross error, but because of a sum of small omissions. Six patterns show up especially often in audits. Each one maps to a concrete WCAG 2.2 success criterion, which makes remediation plannable.
Missing Focus Trap
A modal banner should keep the keyboard focus inside the dialog until a choice is made. Without this trap, the focus moves behind the open dialog (WCAG 2.4.3, 2.4.11).
Not Reachable by Keyboard
Buttons and switches that only work with the mouse lock out everyone who navigates with the keyboard. This violates the fundamental criterion of keyboard operability (WCAG 2.1.1).
Contrast Below 4.5:1
Pale button labels, grey category labels and thin help text often fall below the minimum values for text contrast (WCAG 1.4.3).
No Screen Reader Announcement
Without role=dialog, without a label and without focus handover, the banner stays silent or confusing for screen readers (WCAG 4.1.2, 1.3.1).
Reject Weighted Weaker
If reject is smaller, paler or buried deeper than accept, an unequal weighting arises that is also challenged under data protection law (EDPB).
Targets Too Small
Tiny switches and close icons are hard to hit for users with motor impairments. WCAG 2.2 requires a minimum target size (WCAG 2.5.8).
Contrast: 4.5:1 on Buttons, Labels and Help Text
Low text contrast is by far the most common barrier on the web: the WebAIM Million report 2025 found it on 79.1 percent (WebAIM Million 2025) of the home pages tested, with an average of 29.6 (WebAIM Million 2025) individual instances per page. Consent banners are a prime location for it, because their design often relies on discreet restraint: light grey reject buttons, pale category labels and thinly set explanatory text. What is meant to look understated frequently drops below the readability threshold.
WCAG 2.2 AA sets clear values: normal text needs a contrast ratio of at least 4.5:1 (W3C Web Accessibility Initiative), large text at least 3:1. For graphical controls such as switch borders, checkboxes and the focus indicator, success criterion 1.4.11 requires a minimum of 3:1 (W3C Web Accessibility Initiative). These values can be measured, they are not a matter of taste. A well-maintained design system that stores contrasts as tokens prevents the error at the root; how strongly color contrasts determine readability is shown in practice every day.
Contrast Is Measurable, Not a Matter of Taste
Keyboard and Focus: Trap, Not Dead End
Those who do not use a mouse move through the page with the Tab key. Success criterion 2.1.1 requires every function to be reachable by keyboard, criterion 2.1.2 that the keyboard never gets stuck in a trap (W3C Web Accessibility Initiative). A consent banner has to deliver both at once: inside the open dialog the focus should cycle between the controls and not escape into the page behind it, yet this cycle must not become a genuine dead end from which the choice buttons can no longer be reached. How empty controls sabotage operation is shown by the WebAIM figures: empty buttons on 29.6 percent (WebAIM Million 2025) and empty links on 45.4 percent (WebAIM Million 2025) of home pages.
- Not focusable: A close icon or switch that only responds to a click stays invisible to the keyboard (WCAG 2.1.1).
- No visible focus: Without a clear focus indicator it is impossible to tell which element is currently active (WCAG 2.4.7).
- Focus escapes: With a missing focus trap the tab order jumps behind the banner into the still operable page underneath (WCAG 2.4.3).
- Obscured focus: A fixed banner covers the focused element, so it is not visible where you are (WCAG 2.4.11).
- Escape without effect: The dialog cannot be closed by keyboard or exited with a clear choice.
New in WCAG 2.2: Focus Not Obscured
Screen Readers: The Right Announcement
A screen reader does not read the image but the code. For the banner to be recognized as an independent dialog, it needs a suitable role and a name: role=dialog or a native dialog element, plus aria-modal and a label via aria-labelledby that points to the banner heading. On opening, the focus should move into the dialog so the announcement can even begin. Without this markup, the banner violates the criteria for name, role and value as well as for structure and relationships (WCAG 4.1.2, 1.3.1).
A second blind spot is the category switches. Checkboxes for statistics, marketing or comfort need a programmatically linked label, otherwise the user only hears checkbox checked without knowing what for. Missing form labels were present on 48.2 percent (WebAIM Million 2025) of home pages according to WebAIM, making them one of the most common errors of all. How screen reader optimization and accessible forms work in detail is something we explore in separate articles; in the consent banner the same rules apply as in any other form.
A website is accessible only if it meets the requirements even without an additional aid applied afterwards. That holds for the consent dialog just as much as for the rest of the page.
Reject as Easy as Accept
This is where accessibility and data protection meet. In its guidelines on deceptive design, the European Data Protection Board states that accept and reject must be offered with equal visual prominence on the same level (EDPB). A reject button that is smaller, paler or only reachable after several clicks counts as a deceptive pattern. For accessibility, the same design has a second consequence: the pale reject button falls below the contrast value, and the hidden path lengthens the keyboard route. Taking equal prominence seriously satisfies both sets of rules in one move.
Check for Equal Prominence
Test Criteria by WCAG 2.2 AA at a Glance
The following overview maps the most important success criteria to the concrete errors we encounter in the consent banner. It works as a checklist for your own review, but does not replace a look at the real behavior with keyboard and screen reader. The new criteria of WCAG 2.2 tighten above all the requirements for focus and target size.
| WCAG criterion | Requirement | Common error in the banner |
|---|---|---|
| 2.1.1 Keyboard | All controls usable by keyboard | Switch responds only to a mouse click |
| 2.4.7 Focus Visible | Recognizable focus indicator | No or invisible focus on buttons |
| 2.4.11 Focus Not Obscured | Focused element stays visible | Fixed banner covers the focus |
| 1.4.3 Contrast | Text at least 4.5:1 | Pale reject button and grey labels |
| 1.4.11 Non-text Contrast | Borders and focus at least 3:1 | Barely visible switch outlines |
| 4.1.2 Name, Role, Value | Role and name for assistive tech | Missing role=dialog and aria-label |
| 2.5.8 Target Size | Targets at least 24 by 24 pixels | Tiny switches and close icons |
Implementation in Six Steps
An accessible consent banner is not created by an additional tool, but by clean work on markup, behavior and the design system. The following steps lead from taking stock to provable conformance.
- Set role and structure: Mark the banner as a modal dialog, with role=dialog or a native dialog element, aria-modal and a label via the heading.
- Manage focus: On opening, place the focus into the dialog, keep it inside and return it to the triggering element on closing.
- Check keyboard paths: Reach every button and switch by Tab, with a visible focus and a clear way to leave the dialog.
- Define contrasts: Text at least 4.5:1, borders and focus at least 3:1, stored as tokens in the design system.
- Establish equal prominence: Accept and reject on the first level, in comparable size, contrast and order.
- Test and document: Test with keyboard and screen reader, map every finding to a criterion and record the result in an accessibility statement.
This sequence also connects to the bigger picture. A single tested banner is of little use if the rest of the page remains untested; accessible implementation treats the interface as a whole. A WCAG 2.2 audit provides the prioritized action list for it, and ongoing BFSG monitoring detects when a later update of the consent tool introduces a new barrier.
Sources and Studies