A Consent Banner Accessibility Audit You Can Run in an Hour
The banner is the first interface every visitor meets. A one hour audit covering keyboard, screen reader, zoom, and touch, with a fix list at the end.
Consent banners are audited for legal wording and almost never for usability. Yet the banner is a modal interface placed in front of every visitor, including every visitor using a keyboard, a screen reader, a screen magnifier, or a switch device. A banner they cannot operate is a locked door with a legal notice pinned to it.
This audit takes about an hour on a live banner and needs no specialist tools beyond a keyboard, a free screen reader, and browser zoom. It produces a short fix list ordered by how completely each defect blocks the choice.
Keyboard pass: reach, operate, escape
Start with the mouse put aside. Tab to the banner: can you reach it in a sensible order, see where focus is, operate every control including category toggles and the preferences link, and dismiss or complete the banner without a trap. Note any point where focus disappears behind the page or lands somewhere unexpected after the banner closes.
Check the return journey too. After the banner closes, focus should land somewhere sensible, usually where the shopper was or at the start of the main content, never lost at the top of a page they had already scrolled through.
Screen reader pass: announcement and structure
With a screen reader, reload the page and listen to how the banner announces itself: is it identified as a dialog or region with a clear name, are the categories and their controls labelled as a group, and does accept versus refuse wording read honestly in sequence.
Operate each control by voice output alone and confirm the state changes are announced: a toggle that flips silently leaves the shopper guessing whether their refusal registered, which for a consent control is the worst possible ambiguity.
Zoom, text size, and touch pass
Set browser zoom to 200 percent and then 400 percent, and increase system text size on a phone. The banner should remain fully usable: no clipped buttons, no text cut mid sentence, no controls pushed off screen with no way to scroll to them. Fixed position banners fail here more than any other pattern.
On touch, check target sizes for every control, especially the close icon and individual category toggles, and check that the banner does not cover the whole small screen with no visible route past it. A banner that fills a phone and cannot be dismissed is a refusal of entry, not a request for consent.
Write the fix list by blocking power
Order findings by consequence: controls that cannot be reached or operated at all first, then state and announcement problems, then visual clipping that still allows completion. For each finding, record the device and tool used and the exact steps, so a developer or the banner vendor can reproduce it without a meeting.
Send vendor supplied banner defects to the vendor with the same evidence, and retest after their fix on the live banner, not a demo. Banner accessibility regresses with vendor updates often enough that this audit belongs on a quarterly rhythm, not in a one off project.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Consent Banner Reject and Accept Parity: What Equal Prominence Really Means, Consent Banners and Holiday Popups: Stopping the Overlay Pile Up, and Consent Banners on Multilingual Sites: One Clear Choice in Every Language.
Frequently asked questions
Why audit the banner separately from the site?
Because it is a distinct interface, often vendor supplied, sitting in front of the whole site. A site can pass its audit while its banner blocks the same shoppers at the door, before any audited page is reached.
What is the most common banner accessibility failure?
Keyboard and focus problems: controls that cannot be reached, focus that is invisible or trapped, and focus lost after the banner closes. The screen reader announcement and toggle labelling are the next most common failures.
How long does a useful banner audit take?
About an hour for the keyboard, screen reader, zoom, and touch passes on one banner, plus time to write findings properly. It is deliberately scoped to be repeatable quarterly, not a once a year project.
Who should fix banner defects, the store or the vendor?
The vendor owns code fixes in a supplied banner, and the store owns the audit, the configuration choices, and the retest. Configuration causes many failures, such as faint close controls, and those are fixed in settings the same day.