Cookie Banner Accessibility: Consent That Works With Screen Readers
Consent you cannot operate is not consent
The legal standard for consent is that it is freely given, specific, informed, and unambiguous. An inaccessible banner fails at the first hurdle for disabled users. A screen reader user who cannot tell what the buttons do, a keyboard user trapped in the banner with no way to reach the settings, a low-vision user who cannot perceive the focus indicator: none of them can give the informed, unambiguous consent the law requires.
This is not a theoretical concern. The banner is often the first interactive element on the page, which means it is the first barrier a disabled visitor meets. A site can have a perfectly accessible checkout and still present an unlawful consent experience to a meaningful share of its audience.
The failures, concretely
Keyboard traps are the most common serious failure. The banner appears, focus moves into it, and the user cannot tab out or dismiss it without making a choice they may not understand. For a sighted mouse user this is an annoyance. For a keyboard-only user it is a locked door.
Unlabeled controls come next. Accept and reject buttons built as divs with click handlers, no accessible names, no roles. A screen reader announces nothing useful, and the user is choosing blind. Then there is focus management: banners that appear without moving focus, so screen reader users do not know the banner exists, and banners that disappear without returning focus, leaving the user lost on the page.
State changes are the quiet failure. Toggling a consent category in the preferences panel should announce the change. It usually does not. The user flips a switch, hears nothing, and cannot confirm their choice registered.
What an accessible banner does
The accessible banner follows the same patterns as any good modal dialog, because that is what it is. When it appears, focus moves to it and the purpose is announced. The user can operate every control with a keyboard: tab through options, activate with enter or space, dismiss with escape where dismissal is lawful. When it closes, focus returns to a sensible place.
Every control has an accessible name that says what it does. Accept all, reject all, and customize are real buttons, not styled divs. The preferences panel uses proper form controls: real checkboxes or switches with labels, grouped in fieldsets with legends by purpose. State changes are announced. The whole banner meets color contrast requirements, because consent choices presented in unreadable gray text are not choices.
Why regulators are starting to care
Regulators have begun connecting these dots. Enforcement actions have cited consent interfaces that nudge or confuse users, and accessibility failures are a particularly clear form of confusion. A banner that a disabled user cannot operate is not just a WCAG violation. It undermines the validity of every consent it collects.
Plaintiffs' firms are noticing too. Accessibility demand letters increasingly mention consent banners alongside the usual carousel and form complaints. The banner is high-visibility, easy to test, and legally load-bearing, which makes it an attractive target.
The fix is a sprint, not a project
Most banner accessibility failures are fixed in the banner component, not across the site. Audit the banner with a keyboard and a screen reader, fix the dialog pattern, label the controls, manage focus, announce state changes. Then lock it: add the banner to your accessibility regression tests so the next redesign does not reintroduce the failures.
Consent is the foundation your entire data program stands on. If the foundation excludes disabled users, the program has a hole at its base. Fix the banner, and the consent you collect is valid for everyone.