A cookie banner is the overlay asking permission to set cookies, and it is usually a vendor script laid over the top of a finished page. That makes it the first interactive thing a visitor meets and the component nobody on the team feels they own. WCAG says nothing about cookie banners in particular, so every finding on one comes from a general rule. Keyboard operation, and keyboard escape, both at Level A. The focused element not being entirely hidden behind author-created content, at Level AA. Contrast on the text and the controls, the same as anywhere else. And the third-party argument does not work here, because a consent platform you chose, configured and paid for is content under your control.
In practice
Decide first whether the banner is modal, because half the usual findings only apply if it is. A modal one blocks the page behind it, so focus has to move in, stay in, and have a way out, and Escape is the expected way out. A notice you can ignore and scroll past owes none of that. What it still owes is a keyboard route to every control on it and a focused element you can see. The failures then repeat from site to site. A modal banner that never takes focus. One that lets Tab walk straight out into a page the visitor cannot use yet. Escape doing nothing. No keyboard route to the reject control, and a reject control styled to be harder to find than accept. Only the first four of those are accessibility findings. The last one is a data protection question and belongs in a different conversation, though the grey-on-white styling that usually carries it is a contrast failure you can measure.
The strongest argument you have is the keyboard trap rule, because it is one of four criteria that apply to everything on a page whether you rely on that content or not. A vendor banner that traps focus fails at Level A and cannot be excluded from a conformance claim by pointing at the vendor. The route for third-party content you genuinely cannot control does not stretch this far, because you picked this vendor from a shortlist.
There are three ways past the obscuring problem and W3C names all three. Make the banner modal, so it has to be dismissed before anybody navigates the page behind it. Use scroll padding, so the banner never overlaps the element with focus. Or let it close when it loses focus, which only works for a notice that needs no answer. W3C attaches a caution to the first one, because constraining focus creates an unequal experience between keyboard and pointer users and should be used carefully. And the rule bites only where the focused element is entirely hidden. If any part of it shows, that criterion is met, because the Level AAA version of the rule is the one that allows no obscuring at all. Met is one criterion rather than the page, so the banner still answers to everything else.
Why it matters
If the banner fails, nothing behind it matters, because the visitor never gets past it. The whole checkout, the whole account area, the whole site, gated behind a component the team did not write and rarely tests. A scan will not save you either, and not for the reason people give. Tools that analyse the page after the scripts have run do see the banner, so the old claim that banners hide from automation only holds for tools that snapshot too early. Browser automation can press Tab and Escape as well, so the keystrokes are not the limit. What no tool can judge is whether the place focus landed was the right one, and whether somebody could work out what to do next. That part is done by a person or not at all.
The thirty-second test
Load your site in a fresh private window and press Tab once. Did focus land inside the banner? Now press Escape. Did it close? Now try to reject cookies and reach the page using only the keyboard. Most banners lose on one of those three.
Where this shows up on the site
Related terms
- Modal dialogA modal dialog is a window that opens over the page and blocks everything behind it until it closes.
- Focus trapA focus trap is somewhere on a page that keyboard focus can get into and not out of.
- IframeAn iframe embeds one document inside another.
- Contrast ratioA contrast ratio is a number from 1:1 to 21:1 measuring how far apart two colors are in brightness, computed from a formula rather than judged by eye.
- Keyboard accessibilityKeyboard accessibility means every piece of functionality on the page can be operated through a keyboard interface.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.