Testing a Consent Banner With a Screen Reader: What You Hear Is What Users Get
Run NVDA or VoiceOver, close your eyes, and load your own homepage. What arrives is a wall of navigation, then, somewhere in it, a region that may or may not announce itself as a consent dialog, containing buttons that may announce as accept, or as button, button, button.
Screen reader users make up a real slice of every site's traffic, and the banner is the first transaction they are asked to complete. If the reject control is announced without a name, the consent that follows is not meaningfully informed for that user, whatever the legal team thinks the banner says.
The first sixty seconds
Listen for the landing. When the banner appears, does the screen reader announce a dialog and its title, or does the user have to hunt for it by heading and landmark navigation? A banner that exists visually as a modal but semantically as a stray div at the end of the page forces blind users to discover a blocking element by accident, usually after trying to read content the banner is covering.
Then the buttons, one by one. Accept all cookies announces itself. A control announced as button, or as the filename of an icon, is a defect with a name in WCAG terms: name role value. Customise is the critical one, because it is the door to every granular choice, and if that door is unlabelled the granular consent your privacy notice describes does not exist for screen reader users.
Inside the settings panel
Purposes should be controls, not paragraphs. Each category, necessary, analytics, marketing, in the site's own taxonomy, needs a toggle or checkbox whose state is spoken: switch, off; switch, on. Text that says marketing cookies with a coloured pill beside it conveys state to exactly the users who can see the colour. Locked necessary cookies should be announced as disabled or always active in words, so the user is not left pressing a control that will never respond.
Order matters here too. The panel should read in the order decisions are made, purposes before save, save before close, with headings a user can jump between. A panel that reads the legal description of every cookie before reaching the first toggle is technically labelled and practically unusable.
After the choice
Make a selection and listen to what happens. Is the choice confirmed in words, a polite live region saying your preferences have been saved, or does the banner vanish into silence, leaving the user to wonder whether the save registered? Does focus return to the page content at a sensible point, or does the next keypress restart navigation from the very top of the document?
Record the session, note the banner version and the screen reader and browser pairing, and file it with the accessibility statement work. Then repeat it after the consent vendor's next template update, because markup changes arrive silently and listening is the only audit that hears them.
Related reading
These earlier guides cover connected questions in more depth: Consent Errors You Never See: Logging Failures in the Consent Layer, Geo Targeted Consent Banners: Test the Version You Never See, and When Your Consent Platform Fails to Load: Outage Behavior You Should Set on Purpose.
Frequently asked questions
Which screen readers should a banner be tested with?
NVDA with Chrome or Firefox and VoiceOver with Safari cover the most common pairings. JAWS remains common in workplace settings. Testing one pairing is a start; the banner should behave consistently across them because the semantics, not the tool, are what you control.
What is the most common screen reader failure in banners?
Unnamed or vaguely named controls, especially close icons and customise buttons, followed by purpose toggles that are styled text rather than real switches with spoken states. Both are markup failures in the banner template.
Should the banner be announced as a dialog?
If it behaves as a modal, blocking the page until a choice is made, it should be marked up and announced as a dialog, with focus managed accordingly. If it is a non blocking bar, it still needs a clear landmark or label so it can be found quickly.
Does a passing visual accessibility audit cover the banner?
No. Contrast and font size checks say nothing about announcements, focus order, or control states. The banner needs its own keyboard and screen reader pass, repeated when the vendor updates its template.