Three different things make a cookie banner pass the focus rule, and most teams have only ever met one of them. Make the banner modal, so it has to be answered before anything else on the page. Use scroll padding, so the banner never lands on top of whatever has keyboard focus. Or close the banner the moment focus moves away from it. Any one of the three is enough on its own, and knowing that is worth money, because two of them are far cheaper to build than the one everybody reaches for.
It matters more here than on any other component, because the consent banner is the first interactive thing a visitor meets and it is almost never the thing your team built. It arrives as a third-party script, it loads after everything else, and it covers the page. If a keyboard user cannot get past it, nothing behind it matters, because nobody reaches what is behind it.
The Three Routes Past the Focus Rule
The rule underneath all of this is 2.4.11 Focus Not Obscured, and the word carrying the weight in it is entirely. A sticky banner fails only when it completely hides the component that has focus. Cover half a button and you pass at Level AA, deliberately, because that is what responsive layouts do all day. Cover the whole button and you have the finding.
| Route | What you build | When it fits |
|---|---|---|
| Make it modal | Focus moves into the banner when it appears, stays inside while it is open, and returns to the page when it closes | Almost always. A properly built modal cannot fail this rule, because the thing holding focus is the banner itself |
| Use scroll padding | scroll-padding-top and scroll-padding-bottom set to the height of the banner, so the browser scrolls focused controls clear of it | A banner that is there from the first paint and never moves |
| Close it when focus leaves | The banner dismisses itself the moment focus lands anywhere else | A notice that asks for no answer, such as a cookie note with nothing to choose |
Scroll padding has a limit worth knowing before you reach for it. It changes the scroll the browser performs when keyboard focus moves to something that is off screen. It does not move content that is already on screen. So a consent script that injects late, after the visitor has already tabbed into a field, drops its banner straight onto a control the browser has no reason to scroll again. That is the exact thing most consent platforms do, which is why the modal route ends up being the one most banners should take.
Why Holding the Tab Ring Is a Choice, Not the Requirement
Holding focus inside the banner works, and it is one of five shapes W3C lists for an overlay that sticks around. It is also the only one of the five that carries a warning. Constraining focus potentially creates an inequitable experience between keyboard and pointer users, so it should be used carefully. A pointer user can click anywhere on the page while your banner is up. A keyboard user cannot leave it. Same banner, two different pages.
The other four shapes are on the 2.4.11 page with the rest of the criterion. Push the content down, reflow the page around it, open into empty space, or collapse when focus leaves. A cookie banner rarely gets to use them, because they are written for content the user chose to open. Content the author positions, or content that appears with nobody asking for it, is held to the stricter half of the rule and has to keep the focused item visible from the start.
Where Focus Lands Inside the Banner Has a Consent Consequence
The usual instruction for a modal is to focus the first focusable element inside it. On a consent banner the first focusable element is normally Accept. Move focus there on appearance and the keyboard user's next press of Enter or Space accepts tracking they never read a word about. That is not a technical failure. It is worse, because it passes every test and still takes something from somebody.
The dialog pattern gives you four starting points and asks you to pick by what the dialog holds. The first focusable element for something small and simple. An element at the top carrying tabindex="-1" for something long, so the dialog does not open part-scrolled. The least destructive control where the dialog offers a destructive action. And the most-used control for a dialog that is really just information. A cookie banner is the third of those, because one of its buttons hands away something the visitor cannot easily take back. Send focus to the heading, or to Reject. Never to Accept.
aria-modal Tells a Lie When the Page Behind Is Still Live
Setting aria-modal="true" tells assistive technology that everything outside this element is unavailable, and a screen reader acts on that by hiding the rest of the page. The attribute is only honest when your code actually stops interaction outside the banner and your styling actually covers what is behind it. Consent platforms add it for the announcement and leave the page underneath fully live, which produces a screen reader user shut out of a page everybody else can still click through.
The way to make that claim true rather than merely stated is the inert attribute on the content behind the banner. It takes that content out of the tab order, out of the accessibility tree, and out of pointer events at the same time. The old complaint that the page behind a banner is inert to a mouse and not to Tab describes a bug somebody shipped, not something the platform makes you live with.
How Consent Banners Fail, and Which Failures Are Actually WCAG
| What happens | Who it stops | What it actually is |
|---|---|---|
| Focus never moves to the banner and the banner covers the control that has focus | Keyboard users, and anyone magnifying the screen who sees a fraction of the page at a time | A 2.4.11 failure |
| Tab leaves the banner and runs into the page behind it, which is still live | Keyboard and switch users | A 2.4.11 risk, and inert on the content behind fixes it outright |
| No Escape key and no reachable close, so the only exit is a mouse click on Accept | Anyone who cannot use a mouse | A 2.1.2 keyboard trap |
| Toggles announce as button, with no name and no on or off state | Screen reader users | A 4.1.2 failure |
| Reject is grey text on grey while Accept is a solid button | Low-vision users | A 1.4.3 failure, and separately a consent problem |
| The banner dims the page behind it and the dimming crosses the focused control | Low-vision users, and anyone tracking focus visually | A 1.4.11 failure rather than a 2.4.11 one |
| It asks again on every page load | Everyone, and worst for anyone moving through a site slowly | Not a WCAG failure at all. A usability and consent problem |
That last row is the one we changed our mind about. A banner that reappears on every page load is a real problem and it is not a criterion failure, because no criterion reaches it. Filing it as one puts a finding in your report that a vendor can knock straight out, and a knocked-out finding costs you the credibility of the six rows above it.
The people this hurts are also a wider group than a keyboard test finds. W3C names low-vision users who orient themselves on a page with a pointer, because under magnification a bar across a strip of the viewport covers a far larger share of what they can actually see. It names people with attention limits, short-term memory limits, or difficulty with executive processes as well, who lose their place completely when the thing they were on goes out of sight.
The Reject Button Has Two Contrast Numbers to Hit
Text on Reject needs 4.5:1 against its background, or 3:1 if the text is large, and large means 18 point, or 14 point when it is bold. That is the number everybody checks. The second one gets missed. A Reject styled as a ghost button, thin outline and no fill, is using that outline to tell people it is a button at all, and the outline has its own 3:1 obligation. A ghost Reject with readable text sitting inside a nearly invisible border passes one criterion and fails the other.
Equal prominence between Accept and Reject is a separate argument, and it pays to keep it separate. It is a data protection position rather than an accessibility one. The European Data Protection Board treats consent choices presented with unequal weight as a deceptive design pattern, in guidance written for social media platform interfaces. Cite that as the general cookie banner rule and your client's counsel will notice the scope. Cite the contrast failure and you are standing on WCAG, which holds everywhere.
The Preferences Panel That Opens on Top of the Banner
Most consent platforms have a second layer. Manage preferences opens a panel over the banner, with a toggle for each category. A dropdown, a date picker or a tooltip sits outside the focus rule entirely, because none of them is expected to stay open once you have used it. The moment one of them persists after the visitor has picked something, or after focus has moved away, it becomes exactly the content the rule is about. A preferences panel is built to persist. Treat it as a dialog in its own right, with its own accessible name, its own Escape key, and focus returned to the control that opened it.
Test It Backwards As Well As Forwards
- Load the site in a fresh private window, because a banner that remembers you is a banner you cannot test.
- Press Tab once and look at where focus went. If it is still on the page behind the banner, you have the first failure without doing anything else.
- Tab forward through the banner and out the other side, watching for any point where focus lands somewhere you cannot see.
- Now Shift+Tab back up the same route. This is the pass almost everybody skips, and a banner anchored to the top of the viewport only shows its failure on the way back up.
- Reject the cookies and reach the page using only the keyboard, without ever landing on Accept.
- Press Escape and check what the banner recorded. Silence is not consent, so a banner that reads Escape as acceptance has a data protection problem on top of a keyboard one.
It Is Somebody Else's Script and It Is Still Yours
This is the part owners push back on, and fairly. You did not write the banner. You bought a consent platform, pasted in a snippet, and moved on to something that felt more like your job.
Conformance is claimed for a whole page, and it cannot be claimed with part of the page carved out. There is a partial conformance statement for content genuinely outside your control, your vendor's account manager will find it, so it is worth knowing what it actually covers. It is aimed at user comments, at content injected without your approval, at the parts of a page nobody chose. A consent platform you selected, paid for and configured is a hard fit for that. The route that works is to test the banner, then take what you found to the vendor, because their configuration panel is where contrast and button weighting usually live. A platform that cannot fix either is one to replace at renewal, and a conformance report is a fair thing to ask for before you sign again.
One honest limit
No automated rule exists for this criterion. Not one has been written, and the same is true of both its siblings, so a scanner has nothing conformance-tested to apply to the focus problem this whole page is about. There is a second layer to it. Consent scripts inject late, and a scanner that reads the page before the script has run never sees the banner in the first place. A clean scan on a site with a cookie banner is a reason to test by hand, not a reason to relax.