Cookie consent banners are an important part of any website. They help ensure user privacy, collect consent for cookies, and maintain legal compliance.
However, they’re also a common source of accessibility issues. When not designed properly, cookie banners can confuse users, block navigation, or make it difficult for people using assistive technologies to understand or interact with them.
In this guide, you’ll learn how to make your cookie consent banner accessible for everyone. This includes people using screen readers, keyboards, or other assistive technologies.
How to make a cookie consent banner accessible
Your cookie banner should be easy to understand, simple to navigate, and fully usable with assistive technologies. It should help every user, whether they use a keyboard, screen reader, or magnifier, to make a clear and informed choice.
Here are the key things to focus on to make your cookie banner accessible:
- Position the cookie banner early in the HTML structure
- Add a landmark region with an accessible name
- Announce the cookie modal as new content
- Ensure the banner doesn’t obscure content or focusable elements
- Make the cookie banner or modal fully keyboard accessible
- Make the focus ring clear on every cookie banner control
- Ensure the cookie banner works at 200% zoom
- Use enough colour contrast in the cookie banner
- Write the cookie banner text in plain language
- Use more than colour to show links and active states
You can’t make all of these improvements directly. As a website owner or developer, you can handle the visual and content-related parts, such as writing clear text, choosing readable colours, and deciding where the banner appears on the page.
However, technical accessibility features like keyboard navigation, focus management, and screen reader announcements should come from your Consent Management Platform (CMP). If these features don’t work, ask for a fix or switch to a more accessible solution.
Tip #1: Position the cookie banner early in the HTML structure
What to do: Place the banner markup near the start of the page, immediately after the opening <body> tag, rather than at the very bottom of the DOM.
Why: Keyboard and screen reader users move through the page in DOM order. If the banner is the last thing in the source, a screen reader user may fill in a form or start reading content before they ever learn a consent banner exists, and a keyboard user may have to tab through the entire page to reach it. Because a banner often blocks interaction until it is dismissed, it should be one of the first things a user encounters.
How to do it: Render the banner container as early in the <body> as you can. If you inject it with JavaScript, insert it at the top of the DOM rather than appending it. Confirm the tab order by loading the page and pressing Tab once. Focus should land on or near the banner, not several elements past it.
Example:
<body>
<!-- Cookie banner placed early in the HTML -->
<section id="cookie-banner" aria-labelledby="cookie-heading">
<h2 id="cookie-heading">Cookie Consent</h2>
<p>We use cookies to improve your experience. You can accept or reject non-essential cookies below.</p>
<button>Accept All</button>
<button>Reject All</button>
<button>Customise</button>
</section>
<!-- Skip link appears after the banner -->
<a href="#main-content" class="skip-link">Skip to main content</a>
<!-- Other page content goes here -->
<main id="main-content">
<!-- Placeholder for main website content -->
</main>
</body>Tip #2: Add a landmark region with an accessible name
What to do: Wrap the banner in a landmark region and give it a name assistive technology can announce.
Why: Landmarks let screen reader users jump straight to a region instead of reading through everything before it. A cookie banner with no landmark and no name is just an anonymous block of controls, hard to find on the way in and hard to find again later.
How to do it: Use a <section> or a role="region" with an accessible name via aria-label="Cookie consent" or aria-labelledby pointing at the banner heading. That gives the region a clear label in the screen reader’s landmark list.
Example:
<!-- Cookie banner with a landmark region -->
<section aria-labelledby="cookie_heading">
<!-- The heading provides an accessible name for the region -->
<h2 id="cookie_heading">We use cookies on this site</h2>
<!-- Short and clear description of why cookies are used -->
<p>We use cookies to improve your experience and analyse site usage.</p>
<!-- Action buttons with clear, descriptive labels -->
<button>Accept All</button>
<button>Reject All</button>
<button>Customise</button>
<!-- Link with an accessible, descriptive name -->
<a href="/privacy-policy">Read our Privacy Policy</a>
</section>Tip #3: Announce the cookie modal as new content
What to do: When the banner behaves as a modal, make sure screen readers announce it the moment it appears and that focus moves into it.
Why: A visual user sees the modal pop up. A screen reader user only knows it exists if something tells them. If nothing is announced and focus does not move, they can be left interacting with a page that is now blocked underneath an overlay they cannot perceive.
How to do it: Use role="dialog" with aria-modal="true" and an accessible name for the dialog. On open, move focus to the first control or the dialog heading. Keep focus inside the dialog until the user makes a choice, then return focus to a sensible place when it closes.
Example:
<!-- Cookie modal announced as new content -->
<div
role="dialog" <!-- Identifies this element as a dialog/modal -->
aria-modal="true" <!-- Tells screen readers that focus is limited to this modal -->
aria-labelledby="cookie_heading" <!-- Links the dialog name to the heading below -->
>
<!-- The heading gives the modal an accessible name -->
<h2 id="cookie_heading">Cookie Preferences</h2>
<!-- Short, clear description of why the modal appeared -->
<p>We use cookies to improve your experience. Choose how you want to manage them.</p>
</div>Tip #4: Ensure the banner doesn’t obscure content or focusable elements
What to do: Make sure the banner never permanently covers content or focusable elements, especially when it is fixed to the bottom or top of the screen.
Why: A sticky banner that sits over the page can hide the very element a keyboard user has just focused. This is exactly the failure that WCAG 2.2 added SC 2.4.11 Focus Not Obscured to catch. If a user tabs to a link and the banner covers it, they have lost track of where they are.
How to do it: Prefer a true modal that makes the rest of the page inert while it is open, so there is nothing focusable behind it to obscure. If you keep a sticky banner, add scroll-padding so that focused elements are never hidden underneath it.
Note: scroll-padding is a CSS property that creates extra space between the viewport and the scrolled element. This ensures that important content or focused elements aren’t hidden behind fixed or sticky items like cookie banners or headers.
For more details and technical usage, see the WCAG Technique on scroll padding (opens in a new tab).
Tip #5: Make the cookie banner or modal fully keyboard accessible
What to do: Let users reach, operate, and dismiss every part of the banner with the keyboard alone, and trap focus inside a modal until it is closed.
Why: Plenty of people never use a mouse. If the banner can only be dismissed by clicking, or if focus leaks out to the background while the modal is still open, a keyboard user is stuck. They cannot accept, cannot reject, and cannot get to the site.
How to do it: Ensure every button, link, and toggle is reachable with Tab and operable with Enter or Space. In a modal, trap focus so Tab cycles through the dialog controls only, and make sure focus cannot escape to the background until the user chooses. When the dialog closes, move focus back to a logical spot.
Bad example (see image below): All elements are reachable by keyboard, and the focus order is correct. However, the keyboard focus escapes the modal instead of staying within it, making it confusing for keyboard and screen reader users to interact with the banner properly.
Good example (see image below): All focusable elements are easy to reach using a keyboard, and the focus order follows a logical path. Each element can be activated using the Space or Enter keys, and most importantly, the focus remains trapped within the cookie modal until it’s closed.
Tip #6: Make the focus ring clear on every cookie banner control
What to do: Give every control a visible, high-contrast focus indicator.
Why: Keyboard users track their position by the focus ring. If it is invisible or nearly invisible, they cannot tell which button they are about to press, which means they might accept cookies when they meant to reject. This is WCAG SC 2.4.7 Focus Visible.
How to do it: Do not remove the default outline without replacing it. Provide a custom focus style with a clear, high-contrast outline on every button, link, and toggle. Test it against the banner’s own background, not just the page background, and make sure it stays visible in dark mode.
Bad example (see image below): Here, the focus is currently on the “Decline All” button, but it is hard to see. The outline blends with the button colour, making it unclear for keyboard users.
Good example (see image below): This cookie banner shows a clear focus style. The outlined border around the “Accept all” button makes it easy to see which element is active.
Tip #7: Write the cookie banner text in plain language
What to do: Explain what the cookies do in simple, direct language, without legal jargon.
Why: GDPR Art. 7(2) and Art. 12(1) require consent information to be in “clear and plain language.” If a user cannot understand what they are agreeing to, the consent is weaker, and dense legalese also shuts out people with cognitive disabilities and readers whose first language is not English. Note that GDPR does not specify a reading level. A low reading level is a usability best practice, not a legal or WCAG requirement (WCAG SC 3.1.5 Reading Level is AAA and references a lower secondary education level, not a US grade figure).
How to do it: Say what data you collect and why in short sentences and everyday words. Aiming for roughly a Grade 8 reading level is a reasonable target for a general audience. A free tool like the Hemingway Editor can flag sentences that are too dense.
Bad example (see image below): This cookie banner uses complex language that’s hard to follow. It also includes long sentences filled with unnecessary words that confuse the message.
Good example (see image below): This cookie banner uses plain language to explain what happens when you accept or decline cookies. It keeps the message short, clear, and easy for everyone to understand.
Tip #8: Ensure the cookie banner works at 200% zoom
What to do: Make sure the banner reflows cleanly and stays fully usable when the page is zoomed to 200%.
Why: Many low-vision users browse zoomed in. WCAG SC 1.4.10 Reflow and SC 1.4.4 Resize Text require content to stay usable without horizontal scrolling at high zoom. If your buttons drift off-screen or the “Accept all” control gets clipped at 200%, some users can never complete the choice.
How to do it: Size and space the banner with flexible units like em, rem, and percentages rather than fixed pixel widths. Let the layout wrap. Test at 200% zoom and confirm every button stays inside the banner, nothing is clipped, and scrolling moves the modal content rather than the background.
Bad example (see image below): At 175% zoom, the buttons move outside the modal, breaking the layout. At 200%, most of the “Accept all” button is hidden, and scrolling moves the background content instead of the modal, creating a poor experience for users relying on zoom.
Good example (see image below): This cookie banner works well at 200% zoom. All text stays readable, content reflows properly, and there’s no need for horizontal scrolling.
Tip #9: Use enough colour contrast in the cookie banner
What to do: Meet the WCAG contrast minimums for both the text and the controls in your banner.
Why: Low contrast is the most common accessibility failure on the web, and cookie banners are frequent offenders, especially the faint “Manage preferences” link on a dark banner. Two separate criteria apply: SC 1.4.3 Contrast (Minimum) requires 4.5:1 for normal text and 3:1 for large text (large text being roughly 18pt / 24px, or 14pt bold / about 18.5px), and SC 1.4.11 Non-text Contrast requires a separate 3:1 minimum for the visual boundaries of interactive components such as buttons and form fields. The non-text rule covers active controls; disabled controls are exempt.
How to do it: Check every text and control combination against both ratios, and test in light and dark mode. A free color contrast checker will tell you whether a pairing passes, though passing contrast alone does not make the banner fully accessible. For a deeper look at ratios and testing, see our guide to color contrast and accessibility.
Bad example (see image below): This cookie banner has weak colour contrast. The grey “Change my preferences” link is difficult to see against the dark background.
Good example (see image below): This cookie banner has a strong colour contrast. The text and buttons stand out clearly against the white background, making everything easy to read.
Tip #10: Use more than colour to show links and active states
What to do: Never rely on color alone to signal a link, a state, or whether a toggle is on or off.
Why: Colorblind and low-vision users may not perceive the color difference at all. A green “on” toggle and a grey “off” toggle look identical to some users if color is the only cue. This is WCAG SC 1.4.1 Use of Color.
How to do it: Pair color with a second cue. Underline links, add an icon, or add a text label such as “ON” and “OFF” to toggles. For toggles specifically, expose the state to assistive technology as well, so it is announced and not just shown.
Bad example (see image below): This cookie banner could be clearer. The toggles rely only on colour, which can make it hard for some users to tell whether they’re on or off.
Good example (see image below): This cookie banner uses clear text labels like “ON” and “OFF” along with colour, making the toggle states easy to understand for everyone.
WCAG guidelines that apply to cookie banners
A cookie banner is part of your website.
That means it must also meet the same WCAG (Web Content Accessibility Guidelines) requirements as the rest of your site. If your banner isn’t accessible, users with disabilities may not be able to give or withdraw consent, making both the experience and compliance incomplete.
Below are the key WCAG guidelines that apply to cookie banners:
| WCAG Guideline | What It Means for Cookie Banners |
|---|---|
| 1.4.1 Use of Colour | Don’t rely on colour alone to convey information. Make sure buttons and states (like “On” or “Off”) have clear labels or icons. |
| 1.4.3 Contrast Minimum / 1.4.11 Non-text Contrast | Ensure text and icons have enough contrast against the background so all users can read them easily. |
| 2.1.1 Keyboard / 2.1.2 No Keyboard Trap | Make every element usable with a keyboard. Users should be able to tab into, through, and out of the banner without getting stuck. |
| 2.4.3 Focus Order | When the banner appears, keyboard focus should move to it first, then return to the main content after consent is given. |
| 2.4.7 Focus Visible | Provide a clear focus indicator, like an outline or highlight, for buttons and links in the banner. |
| 1.3.1 Info and Relationships / 4.1.2 Name, Role, Value | Use proper HTML and ARIA roles so screen readers identify the banner, buttons, and links correctly. |
| 1.4.13 Content on Hover or Focus / 3.2.1 On Focus | Announce any content changes, like when the banner appears or disappears, so screen reader users are aware. |
| 1.3.2 Meaningful Sequence | Keep a logical order in the code that matches the visual layout. Users should navigate in the same order they see. |
How the major consent platforms handle accessibility
If you use a consent management platform (CMP), a lot of the banner’s accessibility is decided for you by the vendor.
The table below only summarizes what each vendor publicly states about accessibility on its own website or documentation, with a link so you can check it against the current version. Treat every claim as a starting point, not proof, and verify it yourself using the testing steps in the next section.
| Platform | What the vendor publicly says about accessibility | Source |
|---|---|---|
| Cookiebot / Usercentrics | States its CMP products are certified to WCAG 2.2 Level AA, based on an independent third-party audit, and publishes a VPAT. | usercentrics.com |
| OneTrust (CookiePro) | Says its software complies, or can be configured by customers to comply, with WCAG 2.2 Levels A and AA, and publishes per-module VPATs. | my.onetrust.com |
| CookieYes | Says its banner is “WCAG/ADA compliant,” but names no WCAG version or level and publishes no VPAT. | wordpress.org |
| Complianz | Publishes an accessibility statement describing WCAG/ADA conformance as an ongoing effort; it claims no specific attained level. | complianz.io |
| Osano | Says in its documentation that its cookie consent complies with WCAG (as the basis for ADA compliance), but names no version or level. | docs.osano.com |
| Termly | Makes no public WCAG conformance claim about its own consent banner. | termly.io |
One practical point: know where your control ends. Contrast, copy, and button labels are usually yours to fix through configuration and CSS. Keyboard operation, focus handling, ARIA state, and target sizes are often built into the vendor’s widget, so if those fail you either raise a support ticket or switch tools.
How to test your cookie banner
You cannot tell whether a banner is accessible by looking at it. You have to operate it the way affected users do.
- Keyboard only. Put the mouse away. Tab to the banner, move through every control, operate each one with Enter or Space, and dismiss it. Focus should never get stuck or disappear.
- Screen reader. Test with NVDA in Chrome and VoiceOver in Safari. Confirm the banner is announced when it appears, controls have clear names, and toggle states are read out.
- Zoom. Zoom to 200% and confirm nothing is clipped or pushed off-screen.
- Contrast. Check every text and control pairing against the ratios in Tip #9.
Run them on the live banner rather than a static mockup, and repeat them on a schedule, because banners and CMP widgets change with every update.
Wrapping up
An accessible cookie consent banner may seem like a small detail, but it plays an essential role in creating an inclusive website. It’s often the first thing users encounter, and if it’s confusing or hard to use, it can stop them from engaging with the rest of your content.
By following the tips in this guide, you can make your cookie banner clear, easy to navigate, and compatible with assistive technologies. Small improvements here can make a big difference in how users experience your site and show that accessibility is built into everything you do.
FAQs on cookie banner accessibility
If your site needs to meet WCAG, the banner is part of the site, so yes, it needs to meet the same standard. There is a second reason too: under GDPR, consent has to be freely and clearly given, so if a user cannot read or operate the banner, you have not collected valid consent from them. In the EU, the European Accessibility Act (in force 28 June 2025) makes WCAG 2.1 AA effectively enforceable for many digital services through EN 301 549.
Say, in plain language, what data you collect and why, and give users a clear way to accept all, reject the optional cookies, or manage their choices. Keep sentences short, avoid legal jargon, and give equal weight to accepting and rejecting. GDPR requires clear and plain language (Art. 7 and 12) but does not set a reading level, so a low reading level is best practice rather than a legal rule.
Effectively, yes, for services in scope. The European Accessibility Act came into force on 28 June 2025 and makes WCAG 2.1 AA enforceable across the EU through the EN 301 549 standard, and a cookie banner is part of the digital service it appears on. WCAG 2.2 is expected to become the reference once EN 301 549 v4.1.1 is adopted, anticipated in 2026.
AUTHOR
Melwyn holds a Bachelor's degree in Computer Science and has been writing professionally for over 4 years. He has a strong background in SEO and is certified in web accessibility from the World Wide Web Consortium (W3C). When he's not writing about website optimisation, you can find him enjoying a game of FIFA or exploring the open world of GTA.
Melwyn Joseph 
