The Accessible Cookie Banner: WCAG 2.2 Compliance Guide

Date: June 15, 2026 Author: GetCookies Team Category: Accessibility Reading Time: 12 min

---

Your cookie banner is the first thing users interact with. If a user with a disability cannot navigate it, you are blocking them from your entire site.

Lawsuits under the ADA (Americans with Disabilities Act) and EAA (European Accessibility Act) are increasingly targeting inaccessible overlays.

Here is how to make your GetCookies implementation WCAG 2.2 AA compliant.

1. Focus Trapping

When the modal opens, keyboard focus must be trapped inside it.

• Bad: User presses Tab and focus moves to the background navigation menu (which is visually greyed out).
• Good: Focus cycles only between "Accept," "Reject," and "Preferences."

2. No "Keyboard Traps" in Content

Don't let the user get stuck.

• Requirement: The user must be able to close the banner using the Esc key.
• Our Default: We listen for the Escape keydown event and map it to "Dismiss" or "Minimize."

3. Contrast Ratios

Designers love subtle greys. Accessibility requires contrast.

• Text: Must have a 4.5:1 contrast ratio against the background.
• Buttons: Your "Reject" button (often secondary) must still be readable. Don't make it light grey on white.

4. Screen Reader Labels (ARIA)

Visual cues aren't enough.

• The X Button: Visually, it's an "X." To a screen reader, it must be aria-label="Close Cookie Banner".
• Toggles: In the preference center, toggles must report their state: aria-checked="true" or aria-checked="false".

5. Reduced Motion

Some users have vestibular disorders. If your banner "slides in" or "bounces," respect the prefers-reduced-motion media query.

@media (prefers-reduced-motion: reduce) {
  .cookie-banner {
    animation: none;
    transition: none;
  }
}

Conclusion

Accessibility is not an edge case; it is a fundamental requirement. An accessible banner improves usability for everyone (including power users who just want to hit Tab -> Enter to dismiss it).