Consent Banner Accessibility: Making the Banner Work With Screen Readers

Published 2026-10-25

Consent is only meaningful if the person can actually operate the choice. Yet banners are routinely shipped without a single keyboard test: focus vanishes behind the overlay, the reject option is a low contrast link, and a screen reader reads the banner as an unnamed region with five identical buttons.

Accessibility failures here are not edge cases. They affect a large share of visitors and, increasingly, they are the detail regulators and courts examine when consent quality is questioned. This guide covers the checks that matter and how to run them without specialist tools.

Focus behaviour decides whether keyboard users can consent at all

When a banner appears, keyboard focus should move into it in a predictable place, stay inside while the banner is modal, and return to the page when it closes. Test by loading your site, pressing Tab repeatedly, and watching where the focus indicator goes. If it wanders behind the banner into the page, or disappears entirely, keyboard users are stuck. Non modal banners have a different duty: they must be reachable early in the tab order, not the fortieth stop after the footer links. Note what happens after choosing: a banner that closes but leaves focus at the top of the page forces long distance travel to resume reading.

Labels, roles, and announcements for screen reader users

Screen readers need the banner identified as a dialog or region with a clear label, buttons that say what they do, and toggles whose state is announced. Accept all cookies is a label. Button is not. Preference switches should expose whether they are on or off, and category descriptions should be real text, not images or tooltips that never get read. Try a free screen reader on your own banner and listen to the whole flow, including the preference centre. The experience is often startling the first time: duplicated text, unexplained numbers, and a close icon announced as graphic. Every one of those is fixable in configuration or light code.

Contrast, size, and the reject path

Visual accessibility fails most often on the reject option, styled as a faint text link beside a solid accept button. That pattern is now doubly suspect: it reads as a dark pattern to regulators and it fails contrast requirements for low vision users. Check both buttons against contrast ratios, including on hover and focus states, and make touch targets large enough for shaky hands and small screens. Text should survive browser zoom to 200 percent without the banner breaking or the buttons scrolling out of reach. If your platform cannot meet these basics in its settings, that is a platform problem worth escalating or migrating over.

Language and reading level are accessibility too

A banner written in legal dialect excludes visitors just as effectively as a broken focus order. Plain language, short sentences, and purposes described by what they do rather than by vendor category names help everyone, including people reading in a second language and people with cognitive disabilities. Offer the banner in the languages your site actually serves, with translations reviewed by a human, not pasted from a machine at launch. Finally, test the whole flow with real users if you can: one session with a screen reader user will teach you more than a checklist, and the fixes usually benefit every visitor who finds the banner annoying for reasons they could not name.

Related reading

These earlier guides cover connected questions in more depth: Cookie Consent for Online Booking Tools: The Embed Nobody Scans, Cookie Consent on School Websites: Keeping Pupil Data Out of Trackers, and Consent in Podcast Players and Embedded Audio: The Tracking Nobody Sees.

Frequently asked questions