Skip to content
Start free Sign in

Accessible cookie banner

A banner everyone can answer.

Focus moves into the Kukie.io consent banner and stays there until the visitor chooses, and every control works from the keyboard and with a screen reader, so everyone can answer it.

Why it matters

If they cannot use it, they cannot choose.

A visitor who cannot use your image carousel scrolls past it. A visitor who cannot use your cookie banner cannot make the decision it exists to collect.

The banner comes first, and it is often the only thing on the page that takes a click until it has been answered. Consent is meant to be a free and informed act. A visitor who could not reach Reject all, or could not tell which button their keyboard was on, has not freely refused anything. A visitor who gave up and pressed the only control they could find has not freely agreed either.

None of this is exotic. Accessibility problems in consent banners are ordinary engineering oversights, and they appear in banners that look fine to the person who signed them off. Kukie.io designs its banner against WCAG 2.2 AA. Whether your website as a whole meets an accessibility obligation depends on the rest of the site, so this page describes what the banner does.

Ordinary ways a banner locks people out
  1. Tab leaks into the page behind

    Focus escapes the banner after 2 presses and disappears into a navigation menu the visitor has not consented to yet. Getting back to the question is guesswork.

  2. 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 still works from the keyboard in theory, but nobody can see where they are.

  3. The buttons are not buttons

    Accept and reject are styled boxes with a click handler. A mouse works. A keyboard does not reach them, and a screen reader says nothing useful about them.

From the keyboard

What a keyboard-only visitor experiences.

Here is what happens on a page protected by Kukie.io for someone who never touches a mouse, because of limited dexterity, because they use a screen reader or because they prefer the keyboard. You can follow along on your own site with the Tab key.

  1. Step 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 tells assistive technology that it is a dialog, with a name, rather than an anonymous box of text that appeared.

  2. Step 2: Tab moves between real buttons

    Manage preferences, Reject all and Accept all are real buttons, so Tab reaches them and Enter or the space bar activates them. Any policy links in the banner come first, then the buttons, in this order unless you change it. Each button draws a visible outline while it has focus.

  3. Step 3: Tab does not leak out

    Focus stays inside the banner while it is open. Tab past the last control returns to the first, and Shift-Tab past the first goes to the last. A keyboard user cannot fall into a page they have not yet decided about, or lose the banner and fail to find it again.

  4. Step 4: Preferences behave like preferences

    The preferences panel keeps everything on the keyboard. Category rows open with Enter or the space bar and report whether they are open or closed. Each category switch reports on or off rather than relying on colour. Controls inside a closed category leave the tab order, so Tab never lands on something the visitor cannot see.

  5. Step 5: Escape steps back, not out

    Escape in the preferences panel returns to the banner it was opened from, and focus follows. It does not leave the visitor on the page with the question half answered, which is what people expect from a dialog and what keeps consent meaningful.

  6. Step 6: The answer is announced, and focus goes home

    Once a choice is saved, a screen reader announces that the preferences were saved. Focus returns to whatever the visitor was on before the banner appeared, so they carry on where they were rather than starting again at the top of the page.

None of this is a setting. There is no accessible mode to turn on and no separate accessible banner to choose. It is how the banner is built, so every site gets it.

Visitor settings

The banner follows settings visitors already made.

People who need adjustments have usually made them already, in their operating system or browser. The banner respects those choices instead of overriding them.

Visitor settings the Kukie.io consent banner responds to
What the visitor has set What the banner does Why it matters
Reduced motion Entrance animations and transitions stop. 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 so they do not have to opt out site by site.
Dark colour scheme With Auto Dark Mode on, the default with Custom Colours, the banner switches to a dark palette: a built-in one that keeps your brand colour on filled buttons and lightens it for links, focus outlines and outlined buttons when it would be hard to see on the dark background, or one you choose. A bright white panel over a dark page is painful for light-sensitive visitors, and it is one reason people set a dark scheme in the first place.
Keyboard rather than a pointer Every control draws a clear focus outline when it is focused from the keyboard, and only then. Somebody moving by Tab needs to see where they are. Showing the outline only for keyboard focus spares mouse users a stray ring around a button they have clicked.
A screen reader The banner announces itself as a named dialog, category rows report whether they are open or closed, switches report on or off, and saving a choice is spoken. A change that is only visual is no change at all if you cannot see the screen. State has to be exposed, not implied by colour or position.
Announced to a screen reader
  1. The banner opens

    "We use cookies, dialog"

  2. Manage preferences opens the panel

    "Cookie preferences, dialog"

  3. Tab reaches a category row

    "Analytics, button, collapsed"

  4. Tab reaches its switch

    "Analytics, switch, off"

  5. The choice is saved

    "Cookie preferences saved"

The exact words depend on the screen reader and on the banner text you set.

Colour is the one thing to check

Kukie.io uses whatever palette you give it. When you recolour the banner in banner customisation, Banner Editor measures the text, links and buttons against their backgrounds, in light mode and for any dark mode colours you set, and warns you under the colour field when a pair falls below the ratio WCAG AA asks for: 4.5 to 1 for text. It never changes your colours, so the choice stays yours.

Equal prominence

Equal prominence is an accessibility question too.

The rule that refusing must be as easy as accepting is usually read as a privacy requirement. It is also an accessibility requirement, and that reading tends to get missed.

The imbalance that makes a hidden reject button legally suspect is the same one that makes it exhausting, and it falls hardest on the people with the least patience left for websites.

Kukie.io puts Accept all and Reject all side by side, at the same size, on the first layer of the banner, next to each other in the Tab order. Neither is behind an extra step, and nothing is pre-ticked in the preferences panel. That is the default in every language and every layout. Where a region rule asks for consent first, Reject all also takes Accept all's colour, unless you have set your own colours for those buttons.

This is where accessibility and dark patterns in cookie banners meet. A design that pushes people towards accepting does it by making refusal cost more, and a cost counted in clicks, keystrokes and spoken words never falls evenly.

What a reject button behind a settings screen costs
With a mouse
It takes 2 clicks and a moment of irritation.
From the keyboard
A second dialog to find your way around, a fresh set of controls to tab through, and a decision about whether the effort is worth it.
With a screen reader
All of that, plus listening to the whole panel read out.

Phones and languages

Built for thumbs, and for every reading direction.

Accessibility is also the size of a target, the direction of a sentence and the colours a visitor has forced on their screen. These are built in too.

Targets a thumb can hit

On a phone the buttons stack at full width and 44px tall, and the close button grows to 44px on a touch screen.

Spoken in the right language

The banner tells the browser which language it is in, so a screen reader reads it with the right pronunciation.

Right to left, mirrored

In Arabic, Hebrew, Persian and Urdu the banner reads right to left, and its buttons, switches and close button mirror with it.

Contrast themes respected

In a Windows contrast theme the banner uses the colours the visitor chose, the banner and its panels keep a visible border, and each switch keeps a visible edge and its on or off state.

When it matters most

Where an accessible banner matters most.

Some of every site's visitors use assistive technology or adjusted settings, and none of them announce it. In these situations it also becomes a question somebody will ask you in writing.

  • You are working towards the European Accessibility Act

    Where an obligation covers a website, it covers what is layered on top of it, and the banner is the first thing a visitor meets. Whether you are in scope is a question for your legal advisers, but a banner designed against WCAG 2.2 AA is one fewer thing to fix later.

  • You are a public body, a school or a healthcare provider

    Accessibility obligations reached these sectors first, and the people auditing them are practised. If you already publish an accessibility statement and run reviews, a third-party layer nobody considered is a predictable finding.

  • You have paid for accessibility work

    Accessibility work is measured after the fact, usually by scanning the rendered page, and the banner is part of that page. There is no sense in fixing the contrast on every heading and then putting a keyboard trap in front of them on page load.

  • You build websites for other people

    Agencies and freelancers inherit whatever the consent tool does, and hear about it when it goes wrong. A banner whose behaviour you can describe in a sentence is cheaper than one you test client by client.

    Learn more about Kukie.io for agencies

Every behaviour on this page is part of the banner on every plan, including Free, and none of it is metered.

Learn more about the consent banner

On kukie.io

What we do on our own website.

This part is about kukie.io itself, not the banner we give you, and the two are worth keeping apart.

Every page of this website carries our accessibility widget, in a bottom corner or with Ctrl-U. It 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 comes in the same Kukie.io script as our banner and makes no third-party requests of its own.

We also publish an accessibility statement: 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.

Questions about banner accessibility

What makes a cookie banner accessible?
A visitor can read, understand and answer it however they use a computer. In practice it can be operated entirely from the keyboard, every control shows a visible outline when it has focus, a screen reader is told what the banner is and what happened when a choice was saved, animation stops for visitors who have asked their system for reduced motion, and refusing is no harder than accepting.
Can a cookie banner be used with a keyboard only?
Yes, if it is built for it, and the Kukie.io banner is. 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. Once the choice is saved, focus returns to wherever it was on the page.
What is a focus trap, and why does a cookie banner need one?
A focus trap keeps keyboard focus inside an open dialog 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 past the question into content they have not consented to, and often cannot find their way back to the banner.
Does a cookie consent banner have to meet WCAG?
Where an accessibility obligation covers your website, yes in practice: WCAG is a technical standard rather than a law, but many obligations point at it, and an obligation that covers a website covers anything overlaid on it too. A consent banner is exposed here because it is the first thing a visitor meets and, until it is answered, the only thing they can use. The Kukie.io banner is designed against WCAG 2.2 AA. Whether your site as a whole meets an obligation depends on the rest of your site.
Do I have to switch the accessibility features on?
No. There is no accessibility mode to find and no separate accessible version of the banner. Keyboard operation, the focus trap, screen reader announcements, visible focus outlines and reduced-motion handling are how the banner is built, so every site on every plan gets them from the moment the script is installed. Auto Dark Mode is a setting, on by default with Custom Colours. The one thing to check yourself is colour, because a banner recoloured to match your brand can still end up with text that is hard to read.
Does the European Accessibility Act apply to cookie banners?
Where the Act applies to your website, it does not stop at the consent banner: an obligation that covers a website covers what is layered on top of it. Whether your organisation is in scope, and what it requires of you, is a question for whoever owns your legal compliance rather than something a consent tool can answer. What Kukie.io can do is make sure the banner is not the part that lets you down.

Put a banner everybody can answer on your site.

Keyboard operation, focus trapping and screen reader announcements come with the banner on every plan, including Free.

Related features

Accessibility is a property of the banner rather than a thing beside it. These are the pages where it shows up.

See all features

More on accessible consent

Practical writing on WCAG and cookie consent, keyboard operation and the law pushing it up everyone's list.

See all articles

Disclaimer

Kukie.io provides tools to collect and record consent. It is not legal advice, and using it does not by itself make a website compliant with any law.

Listed on