The short answer
A banner is the first thing many visitors meet, and it often blocks the page. If someone can't reach "Reject all" with a keyboard, can't read it, or can't hear it with a screen reader, they can't make a real choice. Since June 2025, the European Accessibility Act makes this a legal question for many businesses selling in the EU, not just a design one.
Why it matters now
The European Accessibility Act has applied since 28 June 2025. It covers many consumer-facing websites and apps, including online shops, and WCAG 2.2 level AA is the benchmark most people use to judge them. A consent banner is part of the site, so it's in scope.
There's also a consent argument some lawyers make: a choice a person can't perceive or operate isn't a free choice. That's an argument, not a settled ruling, but it points the same way.
The checklist
Choices
- Reject and Accept look the same. Same size, same colour, same weight, 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 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. A clear outline on the focused button, not removed by CSS.
- 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 too.
- Buttons at least 24 by 24 pixels, better 44, 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
- Open your site in a private window. Don't touch the mouse.
- Press Tab. Does focus land in the banner? Can you see where it is?
- Reach "Reject all" and press Enter. Did it work, in the same number of steps as Accept?
- Zoom the browser to 200%. Are both buttons still visible without scrolling sideways?
- 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?
- Check the contrast of the button text with any contrast checker.
If any of those fail, the banner needs fixing before anything else about it matters.
Being honest about where we are
We hold TagSentry's own banner to this list, and publish where it falls short. Our current accessibility statement says the banner is partially conformant with WCAG 2.2 level AA, based on our own testing, with 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. We'd rather say that than claim more.
What the TagSentry banner enforces today: Reject and Accept are locked to the same size and colour, both on the first screen, and a colour you choose that isn't readable enough is blocked from being published.