Cookie banner
Layouts, categories and consent modes
Consent experience
An accessible cookie banner,
because everybody has to answer it
An accessible cookie banner is one every visitor can actually use, including people who navigate by keyboard or screen reader. Kukie's banner is built to WCAG 2.1 AA guidelines: full keyboard operation, a focus trap while it is open, spoken announcements, visible focus outlines, dark mode and reduced-motion support, with accept and reject equally prominent.
A banner nobody can use is a choice nobody can make
Almost every other element on your website is optional. A visitor who cannot use your image carousel scrolls past it. The cookie banner is different: it is deliberately the first thing on the page, it is usually the only thing that will accept a click until it has been answered, and the whole point of it is to collect a decision. If somebody cannot operate it, they have not made a decision. They have been stopped at the door.
That is uncomfortable on its own terms, and it is also awkward legally. Consent is supposed to be a free and informed act. A visitor who could not reach the reject button, or could not tell which button their keyboard was on, has not freely refused anything, and a visitor who gave up and pressed the only control they could find has not freely agreed to anything either.
None of this is exotic. Accessibility problems in consent banners are ordinary engineering oversights, and they show up in banners that look completely fine to the person who signed them off.
Three ordinary ways a banner locks somebody out
-
Tab leaks into the page behind
Focus escapes the banner after two presses and disappears into a navigation menu the visitor has not consented to yet. Getting back to the question is guesswork.
-
The focus outline was styled away
Someone removed the browser's focus ring because it clashed with the design and never replaced it. The banner is still keyboard-operable in theory, but nobody can see where they are.
-
The buttons are not buttons
Accept and reject are styled containers with a click handler attached. A mouse works. A keyboard does not reach them, and a screen reader announces nothing useful about them.
Kukie provides the technical infrastructure for cookie consent, and the banner UI is built to WCAG 2.1 AA guidelines. Whether your website as a whole meets an accessibility obligation depends on the rest of your website, and whether it is compliant with privacy law depends on how you configure consent and may require additional legal measures specific to your organisation. What we can say precisely is what the banner does, which is the rest of this page.
What a keyboard-only visitor experiences
The clearest way to describe a keyboard accessible cookie banner is to walk through one. Below is what happens on a Kukie-protected page for somebody who never touches a mouse, whether because of a motor impairment, because they are using a screen reader, or simply because they prefer it. You can follow along on your own site with the Tab key and nothing else.
-
1
The banner comes to them
When the banner opens, keyboard focus moves into it. There is no tabbing through a header and a cookie policy link to reach the question. The banner also identifies itself to assistive technology as a dialogue with a name, rather than as an anonymous box of text that happened to appear.
-
2
Tab moves between real buttons
Accept, reject and the preferences control are genuine buttons, not decorated containers, so they are reachable by Tab and operable with Enter or the space bar without any extra code making that work. Each one draws a visible outline while it holds focus, so there is never any doubt about which control is about to be pressed.
-
3
Tab does not leak out
Focus is trapped inside the banner while it is open. Tab past the last control and it returns to the first; shift-Tab past the first and it goes to the last. A keyboard user cannot fall into a page they have not yet made a decision about, and cannot lose the banner and be unable to find it again.
-
4
Preferences behave like preferences
Opening the detailed panel keeps everything on the keyboard. Category rows expand with Enter or the space bar and report whether they are open or closed. Each category switch reports whether it is on or off rather than relying on colour. Controls inside a collapsed category are taken out of the tab order, so Tab never lands on something the visitor cannot see.
-
5
Escape steps back, not out
Pressing Escape in the preferences panel returns to the banner it was opened from, with focus following. It does not dump the visitor onto the page with the question half answered, which is the behaviour people expect from a dialogue and the behaviour that keeps consent meaningful.
-
6
The answer is announced, and focus goes home
Once a choice is saved, the banner announces that it has been saved, in the visitor's language, through a live region a screen reader reads out. Focus returns to whatever the visitor was on before the banner appeared, so they carry on from where they were rather than restarting at the top of the page.
None of the above is a setting. There is no accessible mode to switch on and no separate accessible banner to choose. It is how the banner is built, so it is what every site gets.
The banner listens to settings the visitor has already made
People who need accessibility adjustments have usually already made them, in their operating system or their browser, long before they arrived at your website. The most useful thing a banner can do is respect those choices instead of overriding them. Here is what Kukie's banner picks up on its own, with nothing for you to configure.
| What the visitor has set | What the banner does about it | Why it matters |
|---|---|---|
| Reduced motion | Entrance animations and transitions are suppressed. The banner appears rather than sliding, growing or fading in. | Movement on screen can cause nausea, dizziness or migraine for people with vestibular conditions. The setting exists precisely so that they do not have to opt out site by site. |
| Dark colour scheme | The banner switches to a dark palette, either one you have chosen or one derived automatically from your theme. | A bright white panel over a dark page is genuinely painful for light-sensitive visitors, and it is the exact reason many people set a dark scheme in the first place. |
| Keyboard rather than a pointer | Every interactive element draws a clear focus outline as soon as it is focused by the keyboard, and only then. | Somebody navigating by Tab needs to see where they are. Showing the outline only for keyboard focus means mouse users are not left with a stray ring around a button they just clicked. |
| A screen reader | The banner announces itself as a named dialogue, category rows report their open or closed state, switches report on or off, and saving a choice is spoken aloud. | A change that is only visual is not a change at all if you cannot see the screen. State has to be exposed, not implied by colour or position. |
The one thing worth reviewing yourself is colour. Kukie will happily take whatever palette you give it, so if you recolour the banner heavily on the customisation screen, check that the text still reads clearly against its background in both light and dark. The live preview is the fastest place to see it.
Why equal prominence is an accessibility question, not only a legal one
The rule that refusing must be as easy as accepting is usually discussed as a privacy requirement, and it is one. It is also an accessibility requirement wearing different clothes, and the second reading is the one that tends to get missed.
Think about what "buried behind a settings screen" actually costs. For a visitor with a mouse it costs two clicks and a moment of irritation. For somebody driving the page from a keyboard it costs a second dialogue to orient themselves in, a fresh set of controls to tab through, and a decision about whether the effort is worth it. For somebody using a screen reader it costs all of that plus listening to the whole panel read out. The asymmetry that makes a hidden reject button legally suspect is the same asymmetry that makes it exhausting, and it falls hardest on exactly the people who have the least patience left for websites.
Kukie puts accept and reject side by side, at the same size, on the same level of the banner, so both are one keystroke away from the moment the banner opens. Neither is hidden behind an extra step. Nothing is pre-ticked in the preferences panel. That is the default, not a setting you have to go and find, and it is the same default in every language and every layout.
This is where accessibility and dark patterns in cookie banners meet. A design that quietly pushes people towards accepting is doing it by making refusal more expensive, and cost measured in clicks, keystrokes and spoken words is never distributed evenly. A banner that treats both answers the same is easier for everyone and materially easier for some.
Who needs an accessible cookie banner?
Everyone, in the sense that a proportion of every website's visitors uses some form of assistive technology or adjusted setting and none of them announce themselves. But there are situations where the question stops being a good intention and starts being something somebody will ask you about in writing.
You are working towards the European Accessibility Act
This is the reason accessibility has climbed so many roadmaps at once. Where an obligation covers a website, it covers what is layered on top of it, and the consent banner is both the first thing a visitor meets and the only thing they can interact with until it is answered. Whether your organisation is in scope is a question for your legal advisers, but a banner built to WCAG 2.1 AA guidelines is one fewer thing to remediate later.
You are a public body, a school or a healthcare provider
Accessibility obligations arrived in these sectors long before they arrived anywhere else, and the people auditing them are practised. If your organisation already publishes an accessibility statement and runs periodic reviews, a third-party overlay that had never been considered is a predictable and avoidable finding.
You just paid to have your site remediated
Accessibility work is expensive and it is measured after the fact, usually by scanning the rendered page. A consent banner is part of that rendered page. There is no sense in fixing the contrast on every heading and then dropping a keyboard trap in front of the lot on page load.
You build websites for other people
Agencies and freelancers inherit whatever the consent tool does, and get the complaint when it does the wrong thing. Choosing a banner whose behaviour you can describe in a sentence is cheaper than defending one you have to test client by client. The agencies and teams page covers running many sites from one place.
Every accessibility behaviour on this page is part of the banner on every plan, including the free one, and none of it is metered. Compare plans if you need more sites, longer consent retention or your own logo, and see the banner itself for what visitors are being asked in the first place.
And what we do on our own website
This part is about kukie.io, not about the banner we give you, and the two are worth keeping separate. Every page of this website carries an accessibility widget, in the lower right corner or on Ctrl and U, which lets you scale the content, change contrast and saturation, enlarge text and spacing, switch to a dyslexia-friendly font, pause animation, turn on a reading guide or jump between headings and landmarks. It runs entirely from our own servers and makes no third-party requests.
We also publish an accessibility statement covering where this website stands, what we have tested, the limitations we know about and how to tell us when we have got something wrong. We would rather write that down than claim to be finished.
Features this one touches
Accessibility is a property of the banner rather than a thing beside it. These are the pages where it shows up.
More on accessible consent
Practical writing on WCAG cookie consent, keyboard operation and the law that is pushing it up everyone's list.
Cookies
April 4, 2026 · 8 min read
Making Cookie Banners Accessible: A Developer's Guide to WCAG 2.1 AA Compliance
Cookie banners are the first interactive element most visitors encounter, yet many fail basic access...
Read more →
Cookies
March 19, 2026 · 8 min read
Cookie Consent and Accessibility: Meeting WCAG 2.2 Standards in Your Banner
The European Accessibility Act took effect in June 2025, making WCAG 2.2 Level AA the baseline for c...
Read more →
Compliance
July 23, 2026 · 8 min read
Cookie Consent for the EU Accessibility Act 2025
The European Accessibility Act has applied since 28 June 2025, and cookie banners on in-scope servic...
Read more →
Cookies
March 19, 2026 · 8 min read
Cookie Banner Design Best Practices: How to Stay Compliant Without Annoying Visitors
A well-designed cookie banner balances regulatory compliance with a smooth visitor experience. This...
Read more →Accessible cookie banner questions
What site owners ask when accessibility lands on their plate and the consent banner turns out to be part of it.
What makes a cookie banner accessible?
An accessible cookie banner is one that a visitor can read, understand and answer regardless of how they use a computer. In practice that means it can be operated entirely from the keyboard, that every control shows a visible outline when it is focused, that a screen reader is told what the banner is and what happened when a choice was saved, that animation is suppressed for visitors who have asked their system for reduced motion, and that refusing is no harder than accepting.
Can a cookie banner be used with a keyboard only?
Kukie's can. When the banner opens, keyboard focus moves into it, so there is nothing to hunt for. Tab moves between the buttons, Enter or the space bar activates them, category rows in the preferences panel open the same way, and Escape steps back from the preferences panel to the banner. Focus is returned to wherever it was on the page once the choice is saved.
What is a focus trap, and why does a cookie banner need one?
A focus trap keeps keyboard focus inside an open dialogue instead of letting Tab wander into the page behind it. A cookie banner needs one for the same reason it is shown at all: until the visitor has answered, the page behind it is a page they have made no decision about. Without a trap, a keyboard user can tab straight past the question into content that has not been consented to, and often cannot find their way back to the banner at all.
Does a cookie consent banner have to meet WCAG?
WCAG is a technical standard rather than a law in itself, but a great many accessibility obligations around the world point at it, and where an obligation covers a website it covers the whole website, including anything overlaid on top of it. A consent banner is unusually exposed here because it is the first thing a visitor meets and, until it is answered, the only thing they can interact with. Kukie's banner UI is built to WCAG 2.1 AA guidelines. Whether your site as a whole meets an obligation depends on the rest of your site too.
Do I have to switch the accessibility features on?
No. There is no accessibility mode to find and enable, and no separate accessible version of the banner. Keyboard operation, the focus trap, screen reader announcements, visible focus outlines, reduced-motion handling and dark mode are how the banner is built, so they apply to every site on every plan from the moment the script is installed. The one thing worth checking is your own colour choices, because a banner recoloured to sit against your brand can still end up with text that is hard to read.
Does the European Accessibility Act apply to cookie banners?
The European Accessibility Act is the main reason digital accessibility has moved up so many roadmaps, and where an accessibility obligation applies to a website it does not stop at the consent layer. Whether your organisation is in scope, and what exactly is required of it, is a question for whoever owns your legal compliance rather than something a consent tool can answer for you. What Kukie can do is make sure the banner is not the part that lets you down.
Put a banner on your site that everybody can answer
Free plan, no card required. Keyboard operation, focus trapping and screen reader announcements come as standard.
