# An accessible cookie banner: a practical checklist What an accessible cookie banner needs: equal buttons, keyboard focus, contrast, screen readers, the European Accessibility Act, and a 10-minute test. _The TagSentry team · September 8, 2026 · https://tagsentry.ai/blog/cookie-banner-accessibility_ > **The short answer:** A banner is the first thing many visitors see, and it often covers the page. Someone who can't reach "Reject all" with a keyboard, can't read the banner or can't hear it with a screen reader has no real choice. Since June 2025 the European Accessibility Act has made this a legal question for many businesses selling in the EU, as well as a design one. ## Why this is a legal question now The European Accessibility Act has applied since 28 June 2025. It covers many consumer-facing websites and apps, online shops among them, and most people judge those against WCAG 2.2 level AA. A consent banner is part of the site, so it's covered too. Some lawyers add a consent argument: if a person can't perceive or operate the choice, they didn't choose freely. No ruling has settled that yet, though it points the same way. ## The checklist ### Choices - **Reject and Accept look the same.** Same size, colour and weight, and both on the first screen. A tiny grey "Reject" next to a big "Accept" is the most common complaint about banners, and [European regulators treat a harder-to-find reject](/blog/got-a-cookie-demand-letter) as a problem in its own right. - **One click to say no.** "Reject all" shouldn't be behind "Settings" or "More options". - **Plain labels.** "Reject all" and "Accept all" beat "OK" and "Manage". ### Keyboard - **Focus moves into the banner** when it opens, so a keyboard user doesn't have to tab through the whole page first. - **Every control is reachable with Tab** and works with Enter or Space. - **Focus is visible.** The focused button has a clear outline, and your CSS doesn't remove it. - **Focus returns** to something sensible when the banner closes. - **Escape does something predictable**, and never counts as "Accept". ### Seeing it - **Text contrast of at least 4.5:1** against the banner background (WCAG 1.4.3), button text included. - **Buttons at least 24 by 24 pixels**, or 44 if you can, so they're easy to hit on a phone (WCAG 2.5.8). - **Works at 200% zoom and on a 320-pixel-wide screen** without cutting off buttons. - **Doesn't rely on colour alone** to show which option is which. ### Hearing it - **It's announced.** Use a dialog role with a label, so a screen reader says "Your privacy choices, dialog" when it appears. - **Buttons have real text**, not just icons. - **The language is marked.** If the banner is in German on an English page, mark it with `lang="de"` so the screen reader pronounces it correctly. - **The page behind is inert** while a blocking banner is open, so a screen reader can't wander into content behind it. ### Coming back - **Visitors can change their mind** from a link or button that stays available, like a small "Privacy choices" launcher. - **That launcher is accessible too**, with a label and a large enough hit area. ## Test yours in ten minutes 1. Open your site in a private window. Don't touch the mouse. 2. Press Tab. Does focus land in the banner? Can you see where it is? 3. Reach "Reject all" and press Enter. Did it work, in the same number of steps as Accept? 4. Zoom the browser to 200%. Are both buttons still visible without scrolling sideways? 5. Turn on your computer's screen reader (VoiceOver on a Mac, Narrator on Windows) and reload. Is the banner announced? Are the buttons read with their names? 6. Check the contrast of the button text with any contrast checker. If any of those fail, fix that before you worry about anything else on the banner. ## Where our own banner stands We hold TagSentry's own banner to this list and publish where it falls short. Our current [accessibility statement](/trust) says the banner is partially conformant with WCAG 2.2 level AA, based on our own testing. There are known gaps we're working on: marking the language of parts of the page, and making the page behind the banner inert. We haven't had an outside audit yet, and we'd rather say so than claim more. Two things [the TagSentry banner](/consent) enforces today. Reject and Accept are locked to the same size and colour, both on the first screen. And if you pick a colour that isn't readable enough, you can't publish it. ## Sources - [Davis Wright Tremaine: The European Accessibility Act and digital products](https://www.dwt.com/insights/2025/07/european-accessibility-act-digital-products) - [Complianz: Cookie banners and the European Accessibility Act](https://complianz.io/best-practices-for-ensuring-your-cookie-banner-complies-with-the-european-accessibility-act-eea/) - [W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) - [r/webdev: cookie banners as accept-all traps](https://www.reddit.com/r/webdev/comments/1w2wwuk/_/p6vxjq7/)