Cookie Consent

An accessible cookie consent banner with granular preference controls that lets users make informed choices about data collection.

Demo

Review the cookie consent banner below. Use Tab to move between the preference toggles and action buttons. Toggle individual cookie categories on or off, then use the primary action buttons to accept, reject, or save your preferences. Notice how the banner communicates its purpose and all controls are reachable without a mouse.

What to Observe

The banner is announced as a landmark or region so screen reader users can navigate to it directly.
Each cookie category toggle has a clear label and communicates its current on/off state to assistive technology.
All action buttons — accept, reject, and save preferences — are reachable and operable with the keyboard alone.
Required categories are marked as disabled and their locked state is communicated to screen readers.
After a preference action is taken, the banner is dismissed and focus returns to a logical location in the page.

Anatomy

[Anatomy image placeholder — will be added when assets are available]

Banner container — The outermost region, typically marked with role="dialog" or an appropriate landmark, that holds all consent content.
Heading — A descriptive title that names the purpose of the banner and serves as the accessible name for the region.
Description text — A plain-language explanation of what cookies are used for and how preferences affect the experience.
Category toggles — Individual switch controls for each cookie category (for example, analytics, marketing), each with a label and state.
Action buttons — Primary and secondary buttons for bulk actions such as "Accept All," "Reject All," and "Save Preferences."

Accessibility Behavior

The banner must be identified as a distinct region so screen reader users are aware of its presence without having to stumble across it.
Each toggle must communicate its current state — on or off — to assistive technology, not just visually.
Mandatory cookie categories must be marked as non-interactive and that restriction must be conveyed programmatically, not only through visual styling.
All interactive controls must be operable using only a keyboard, in a logical tab order.
When the banner is dismissed, focus must move to a predictable location so keyboard users are not stranded.
The banner must not trap focus — users should be able to bypass it and return to page content if they choose to act later.

Common Mistakes

Rendering the banner as a purely visual overlay with no ARIA landmark or role, making it invisible to screen reader navigation.
Using CSS-only toggle switches without underlying checkboxes or buttons, so the state is never communicated to assistive technology.
Disabling required-category toggles only with a visual style change rather than a disabled attribute or aria-disabled, leaving the restriction unexplained.
Not managing focus when the banner closes, leaving keyboard users positioned at the top of the page or in an undefined location.
Writing button labels like "OK" or "Yes" that have no meaning out of context, making it impossible to distinguish accept from reject by label alone.

Why This Matters

Cookie consent is a legal requirement in many jurisdictions, and inaccessible consent mechanisms mean that users with disabilities cannot exercise their data privacy rights on equal terms. A screen reader user who cannot operate the preference toggles has no meaningful choice — they are effectively forced into whatever the default configuration is. Beyond the legal risk, inaccessible consent flows undermine user trust and signal that the product was not designed with all users in mind.

Accessibility Validation

This component is validated against internal accessibility criteria aligned with WCAG standards, using our internally developed system, Resonance Specs.

To learn more, please contact us.