WCAG 2.1 and 2.2 rules for cookie consent banners

A cookie consent banner on a site the European Accessibility Act covers has to meet WCAG 2.1 Level AA, because the Act works through the harmonised standard EN 301 549, which follows WCAG 2.1 AA. WCAG 2.2, the current W3C version, adds two AA criteria that banners often fail: Focus Not Obscured (2.4.11) and Target Size (2.5.8). This article sets out which criteria apply to a banner, who the Act covers and what an inaccessible banner means for consent under the GDPR.

Accessibility rules now reach the cookie banner

The European Accessibility Act (EAA) has applied since 28 June 2025. It covers the products and services it lists, such as e-commerce, banking services, e-books and passenger transport services. A cookie banner on a covered website is part of that service.

The Act exempts microenterprises that provide services: businesses with fewer than 10 staff and an annual turnover or balance sheet total of no more than EUR 2 million. A business with 10 or more staff, or with both turnover and balance sheet above EUR 2 million, is not a microenterprise and is covered for the services the Act lists. Germany's transposition, the BFSG, sets the exemption out in section 3.

An inaccessible cookie banner creates a double problem. Under the EAA, it is an accessibility failure in a covered service. Under the GDPR, consent collected through an unusable interface may not count as freely given, specific, informed and unambiguous, the four conditions in Article 4(11). A visually impaired visitor who cannot perceive the reject button has not been given a real choice.

The EAA's presumption of conformity runs through EN 301 549, whose web requirements follow WCAG 2.1 Level AA. WCAG 2.2, published in October 2023, includes everything in 2.1 and adds new criteria. Meeting 2.2 AA therefore also meets 2.1 AA, and the W3C recommends using the latest version.

WCAG success criteria that apply to cookie banners

Not every WCAG criterion is equally relevant to a consent banner. The table below highlights the ones that matter most.

Criterion 2.4.11, Focus Not Obscured, is the one bottom bars fail most. A bar fixed to the bottom of the screen can cover the link a keyboard user has just tabbed to on the page behind it. If your banner uses a modal pattern with an overlay, mark the page behind it inert so assistive technologies and the keyboard cannot reach content the visitor cannot see. If it does not, keep the focused page element clear of it.

Keyboard navigation is the most common failure

Keyboard accessibility is the most frequent problem with cookie banners. If a visitor using a keyboard cannot tab through the banner, reach the reject button or switch categories on and off, the consent mechanism is broken for that visitor.

Keep the tab order logical and the same as the visual order, and give "Accept all" and "Reject all" equal weight there, as you do on screen. Each element must respond to Enter or Space exactly as it would to a click.

A common mistake is building cookie category switches from <div> or <span> elements styled to look like switches. Keyboard users cannot reach them unless you add role="switch", tabindex="0" and aria-checked, plus key handling. Native <input type="checkbox"> or <button> elements are keyboard-accessible by default and need less custom work.

Screen reader compatibility and ARIA roles

A screen reader user hears your banner read aloud. If the HTML structure is unclear, the experience becomes a wall of unlabelled buttons and mystery switches.

Mark the banner container with role="dialog" and give it a name, such as "Cookie consent", through aria-labelledby or aria-label. This tells assistive technology that a dialog has appeared. When the banner opens, move focus to it so screen reader users are not left in the page beneath. The code for all of this, step by step, is in the guide to cookie banner screen reader and keyboard accessibility.

Each button needs a clear accessible name. "Accept all cookies" is better than "OK". "Reject all" is better than a bare "X" icon. If your banner design uses icons without visible text, give them an aria-label.

Category switches should announce their state, such as "Analytics cookies, off" or "Analytics cookies, on". The aria-checked attribute on a role="switch" element does this.

Colour contrast and visual design

Contrast failures are easy to introduce and easy to fix. WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 between text and its background for normal-sized text, and 3:1 for text of 18 point or larger, or 14 point bold.

Light grey text on a white background, a surprisingly popular choice for the reject option, usually fails. Pastel switches on a light banner often fall below the 3:1 non-text contrast of criterion 1.4.11.

Button parity matters for accessibility too. If "Accept" is a bright, high-contrast button and "Reject" a faint text link, you have a dark pattern concern and a measurable contrast problem. Both actions should carry equal visual weight and meet the same contrast standard.

Focus indicators that stay visible

At Level AA, a keyboard focus indicator must be visible (2.4.7) and, as a visual part of the control, contrast at 3:1 with the colours next to it (1.4.11). WCAG 2.2 adds 2.4.11 at AA, so the focused element is not entirely hidden, and 2.4.13 Focus Appearance at AAA, which sets a minimum size and contrast for the indicator itself.

In practice, banner buttons should show a clearly visible outline when focused with the keyboard. A 2px solid outline in a contrasting colour is the simplest reliable approach.

Avoid outline: none in your CSS. This single declaration removes the browser's default focus indicator and causes most focus visibility failures. If you customise the focus style, replace it with something at least as visible, never with nothing.

Modal behaviour and focus management

Many cookie banners act as modals: they appear over the page and expect a choice before the visitor continues. Modal behaviour brings specific accessibility requirements.

When a modal banner opens, focus should move to the dialog, and the inert attribute on the rest of the page keeps keyboard users out of hidden content. When the banner closes after a choice, focus should return to the element that had it before, or to a logical starting point on the page. A banner that does not block the page should not hold focus at all: it should never hide the focused element.

Pressing Escape is a convention for closing dialogs. Whether your cookie banner should close on Escape depends on your GDPR consent model. If closing the banner without a choice keeps non-essential cookies off, closing on Escape can work. If closing would leave no choice recorded and nothing decided, keep the banner open until the visitor chooses.

Testing your banner for accessibility

Automated tools catch some issues but miss many. A thorough check combines automated scanning with manual testing.

Start with automated checks. Browser extensions like axe DevTools, or the Lighthouse audit in Chrome's developer tools, flag contrast failures, missing ARIA attributes and elements without accessible names. They find only part of the problems, so treat a clean automated report as a starting point.

Manual keyboard testing is essential. Put the mouse away and try every action the banner offers with the keyboard alone. If any step is impossible without a mouse, the banner fails.

Screen reader testing completes the process. Test with VoiceOver on macOS, NVDA on Windows or TalkBack on Android. Listen for whether button labels make sense, whether switch states are announced and whether the banner is identified as a dialog. If your site serves visitors across the EU, also check that your multilingual banner stays accessible in every language, with the right lang attribute for each.

Common accessibility mistakes in cookie banners

These issues appear again and again in accessibility audits of consent banners:

• Custom switches built from <div> elements with no keyboard support or ARIA roles
• A reject button styled as a low-contrast text link while Accept is a prominent button
• outline: none applied globally, removing all focus indicators
• A modal banner that lets keyboard users tab into content hidden behind its overlay
• A bottom bar that covers the element the keyboard user has just focused
• No role="dialog" or name on the banner, so screen readers do not announce it
• A close button labelled only with an "X" character and no accessible name
• Tap targets smaller than 24 by 24 CSS pixels with too little space around them (2.5.8, AA), while 44 by 44 is the stricter AAA target in 2.5.5

Each of these is fixable with standard HTML and ARIA patterns, and the effort is modest compared with excluding the visitors who meet them.

EAA enforcement and penalties

Each EU member state sets its own penalties under the European Accessibility Act, and market surveillance authorities in each country enforce it. In Germany, the BFSG allows fines of up to EUR 100,000 for the more serious breaches and up to EUR 10,000 for the others, under section 37. Other countries set their own amounts.

The microenterprise exemption applies to services only, and GDPR consent requirements apply whatever the size of the business. Accessibility complaints can also feed into regulatory reviews of a consent mechanism: a data protection authority looking at a consent complaint may consider whether the banner was usable by everyone when it assesses the consent collected.

Questions about WCAG and cookie banners

Start from a banner built for keyboards and screen readers

The Kukie.io banner is designed against WCAG 2.2 Level AA: named dialogs, keyboard operation, announced choices and reduced motion, with your own colours and text. Conformance belongs to your whole page, so check the colours you choose, and see what else Kukie.io does on the features page.

Start free