The cookie notice is often the first thing anyone meets on your site, before the menu, before the headline. For most visitors it takes one click to dismiss. For someone on a keyboard, it may be the last thing they reach in the tab order, after every link on the page. For a screen reader user, it may sit silently over the content while they try to read what is underneath.
Cookie banner accessibility gets less attention than menus or forms, partly because the banner usually comes from a plugin or a third-party script that nobody on the team built. But it appears on every page, so its barriers repeat everywhere. This post covers keyboard reach, focus order, contrast, wording, consent plugins and how to keep the banner from blocking content. It does not cover which privacy laws apply to you; that is a question for whoever advises you on privacy.
Why the banner matters more than its size suggests
A consent banner shows up on the first page view, on every template. If a keyboard user cannot reach the “Accept” or “Reject” button, two things can happen. Either the banner covers part of every page they visit, or, on sites where the banner blocks the page until a choice is made, they cannot use the site at all.
It also comes before people have learned anything about how your site works. A confusing first impression on a menu is recoverable. A banner that will not close is often where someone gives up and leaves.
Can a keyboard user reach it?
Check this before anything else. Many banners are injected at the bottom of the page’s HTML, so in the tab order they come after the header, the content and the footer. Visually they sit at the top or bottom of the screen; to the keyboard, they are miles away.
Try it on your own site:
- Open the site in a private browser window so the banner appears.
- Click the address bar, then press Tab once. Where does focus land?
- Keep pressing Tab and count how many stops it takes to reach the banner’s first button.
- Press Enter on “Accept” or “Reject” and check the banner actually goes away.
- If there is a “Settings” or “Preferences” button, open it and Tab through every toggle inside.
Ideally the banner’s controls come first, or very early, in the tab order. That usually means the banner markup sits near the top of the page body, or the script moves focus to the banner when it appears, depending on how the banner behaves.
Banner or modal?
It helps to decide which kind you have, because they need different behavior.
| Type | What it does | Keyboard behavior it needs |
|---|---|---|
| Non-blocking bar | Sits at the top or bottom; the page still works behind it | Early in the tab order, easy to reach, must not cover focused content |
| Blocking dialog | Dims or locks the page until a choice is made | Moves focus inside, holds it there, returns it when closed, labeled as a dialog |
If yours is the blocking kind, it is a modal, and everything in our guide to accessible popups and modals applies: focus in, focus held, a clear way out, focus returned.
Focus that stays visible and uncovered
A non-blocking bar fixed to the bottom of the screen has a side effect people rarely notice. As a keyboard user tabs down the page, the focused link can slide underneath the bar and disappear. WCAG 2.4.11 Focus Not Obscured (Minimum), added in 2.2, is about exactly this: the focused item should not be entirely hidden by content the author put there.
Fixes include adding bottom padding to the page equal to the banner’s height while it is showing, using scroll-padding-bottom so focused elements scroll clear of it, or simply making sure the banner is dismissed easily and early. A compact banner covers less.
The buttons inside the banner need a visible focus style too. Consent tools often ship their own button styles, and some remove the outline. If you cannot see where focus is on “Accept” versus “Reject”, neither can your visitors.
Contrast and size in cookie banner accessibility
Banners are often designed to look subtle, which is where contrast problems come in. Light gray text on a white bar, or a “Reject” link in pale type next to a bold “Accept” button, are common. Text in the banner needs to meet 1.4.3 Contrast (Minimum): 4.5:1 for normal text and 3:1 for large text. Button borders and toggle switches in the settings panel need 3:1 under 1.4.11 Non-text Contrast. Our post on color contrast ratios under WCAG shows how to check them.
Toggle switches deserve a closer look. Many consent settings panels use a small sliding switch for each cookie category, where the only difference between on and off is a color change. That is hard for people with low vision or color blindness. A switch with a visible on/off label, or a plain checkbox, is clearer.
Check size as well. Under 2.5.8 Target Size (Minimum), a close X or toggle smaller than 24 by 24 CSS pixels only passes when spacing keeps it clear of neighboring targets.
Wording people can understand
Accessible cookie consent is partly about words. A banner full of legal phrasing is hard for everyone and harder still for people with cognitive disabilities or anyone reading in a second language. Some practical points:
- Keep the main message short. One or two plain sentences saying what you use cookies for and that people can choose.
- Let each button say its action. Labels like “Allow all cookies”, “Only necessary cookies” and “Choose cookies” are clearer than “OK”, “Got it” or a lone “X”.
- Make the choices equal. If “Accept” is a big button and “Reject” is a tiny text link, that is a design problem for everyone, and especially for people who struggle to find small targets.
- Label each category clearly in the settings panel, with a short description a person can actually follow.
- Link to the full policy with descriptive link text such as “Read our cookie policy”, not “here”.
If the banner has a heading, use a real heading element or give the dialog an accessible name, so a screen reader announces something like “Cookie choices” rather than starting mid-sentence.
Consent plugins and third-party scripts
Most WordPress sites get their banner from a consent plugin or from a script provided by a consent service. The quality of the markup varies a lot between tools, and between versions of the same tool. A few things to know before you pick or keep one:
- Test the vendor’s demo with a keyboard before installing. A short run with Tab, Enter and Escape shows how the banner really behaves, whatever the sales page says.
- Look at the styling options. If the tool lets you set colors, set them for contrast, not just brand match. If it lets you add custom CSS, that is often where focus outlines can be restored.
- Check the settings panel separately. The first-layer banner may be fine while the detailed preferences screen is not.
- Retest after updates. A new version of the plugin can change the markup completely.
When the banner is loaded from a third-party script, you may not be able to change its HTML at all. In that case your options are the tool’s own settings, any custom CSS it allows, or switching to a tool with better output. Installation itself is covered in setting up cookie consent on WordPress, and whether your site needs a cookie banner covers the broader question.
Not blocking content without reason
A banner that covers half a phone screen, or a full-page wall that hides everything until someone clicks, is a barrier in itself. People who zoom in feel it most: at high browser zoom, a bottom banner can take up most of the visible area, and the buttons may scroll out of reach. Check your banner at 400 percent zoom on a desktop browser, which is roughly what WCAG 1.4.10 Reflow means by 320 CSS pixels wide. Can you still read the text and press the buttons?
Some practical habits help:
- Keep the banner compact, with the detail in the settings panel.
- Let people keep reading the page while the bar is showing, unless you have a clear reason to block it.
- Remember the choice so the banner does not return on every page.
- Provide a link, often in the footer, where people can reopen their cookie choices later. Make that link reachable by keyboard like any other.
Where it fits in the wider work
Cookie banner accessibility is rarely a problem on its own. The banner is one of several things that sit on top of every page, along with chat buttons, popups and sticky headers. On a WordPress site, these overlays are best tested together, because they compete for the same screen space and the same spot in the tab order. Our guide to making a WordPress site accessible, step by step shows where overlays fit among theme, content and form work. For audits, fixes and ongoing checks across all of it, our website accessibility hub is the place to start.
Frequently asked questions
Does a cookie banner have to meet WCAG?
The banner is part of your page, so the same WCAG 2.2 AA criteria apply to it as to any other content: keyboard access, visible focus, contrast, target size, clear labels and not hiding focused content. Because it appears on every page, any barrier in it repeats across the whole site.
Should focus move to the cookie banner when the page loads?
For a blocking banner that locks the page, yes: move focus inside it and keep it there until a choice is made. For a non-blocking bar, it is usually enough to place it early in the tab order so keyboard users reach it within the first few presses of Tab.
Are toggle switches in cookie settings accessible?
They can be, if each switch is a real control with a label, announces whether it is on or off, works with the keyboard and shows its state with more than color. Many styled switches miss one of these. A plain checkbox with a clear label is often the more reliable option.
What if my consent tool cannot be changed?
Use what the tool allows: color settings for contrast, custom CSS for focus outlines and sizes, and its options for placement and wording. If the core problems remain, such as buttons that cannot be reached by keyboard, it is worth testing other consent tools and switching to one with better markup.
Cookie banners, chat buttons and popups are part of the overlay checks we do on WordPress sites, alongside the theme, menus and forms. If you want help with yours, see our accessibility services for WordPress.
Next in this series: How to Keep WordPress Accessible After Updates
