Why Accessibility and Consent Now Overlap

GDPR requires that consent be obtainable by every user, not just those who can see and click a banner. The European Data Protection Board has clarified that if a data subject cannot meaningfully interact with the consent interface — due to a disability the site has not accommodated — consent is not validly obtained. That means the cookies should never have loaded in the first place.

On the accessibility side, the European Accessibility Act (EAA) transposed into national law across EU Member States makes WCAG 2.1 AA the minimum for private-sector websites and apps offering consumer services. The penalty regime varies by country but typically ranges from €50,000 to €500,000 per infringement, plus market withdrawal orders for persistent non-compliance.

The Core WCAG Requirements for Cookie Banners

Keyboard Operability

Every banner control — Accept, Reject, Manage Preferences, close — must be reachable and operable with only the keyboard. Users should be able to Tab through buttons in a logical order and activate them with Enter or Space. Focus must be visible with a minimum 3:1 contrast ratio against the background.

Focus Trapping in Modal Banners

If the banner blocks interaction with the rest of the page, keyboard focus must be trapped inside the banner until the user makes a choice. Users should not be able to Tab out of the banner to scroll the underlying page. When focus was trapped and the banner closes, focus should return to the element that triggered the banner or to a sensible default.

Screen Reader Announcements

The banner must be announced as a dialog with an accessible name and role. Use `role="dialog"` or `role="alertdialog"` with `aria-labelledby` pointing to the banner heading and `aria-describedby` pointing to the explanatory text.

Colour Contrast

Body text must meet 4.5:1 contrast against the background; large text (18pt+ or 14pt bold) needs 3:1. Button text, icons, and focus indicators all have their own contrast minimums. A light-grey "Reject" button on a white background is a frequent WCAG failure we see in audits.

No Colour-Only Cues

Do not rely solely on colour to differentiate Accept from Reject. Use distinct labels, icons, or shapes so users with colour blindness can tell the buttons apart.

Dark Patterns and Accessibility

WCAG 2.2 introduces new criteria that directly target dark patterns — especially relevant for consent:

• 3.3.8 Accessible Authentication — forbids cognitive puzzles as consent friction.
• 3.3.7 Redundant Entry — users should not have to re-enter information just to withdraw consent.
• 2.4.11 Focus Not Obscured — the banner itself should not obscure the focus indicator of elements behind it.
• 2.5.7 Dragging Movements — if your banner uses a drag-to-accept interaction, a single-pointer alternative must exist.

RTL and Internationalization

Accessibility extends to right-to-left languages (Arabic, Hebrew, Persian, Urdu) and to screen reader pronunciation:

• Set `dir="rtl"` on the banner when the document language is RTL so button order and focus flow match reading direction.
• Use correct `lang` attributes on translated banner copy so screen readers pronounce words with the right phonetics.
• Mirror iconography — chevrons, arrows, and progress indicators should flip for RTL locales.

Testing Your Banner for WCAG Compliance

Do not rely on a single tool. Combine automated scanning with real assistive-technology testing:

• axe DevTools or Lighthouse — catches roughly 30-40% of WCAG failures automatically.
• NVDA or JAWS on Windows, VoiceOver on Mac/iOS, TalkBack on Android — test with real screen readers. Can the banner be announced, navigated, and dismissed using only the screen reader?
• Keyboard-only navigation — unplug your mouse. If you cannot Accept, Reject, and manage preferences, neither can keyboard users.
• Colour-blindness simulation — Chrome DevTools has built-in vision deficiency simulators. Check that Accept and Reject are distinguishable under protanopia, deuteranopia, and tritanopia.
• Zoom to 400% — WCAG requires content to remain usable at 400% zoom without horizontal scrolling. Fixed-position banners often fail this test.

Common Accessibility Failures We See

• Hidden Reject behind a cogwheel icon — dark pattern plus accessibility failure (no accessible name on the icon button).
• Focus never reaches the banner — banners that steal visual attention but are skipped in the Tab order.
• Modal banner without focus trap — users can tab into the background page while the banner claims to block interaction.
• No `aria-live` on preference changes — screen reader users do not hear confirmation that their choice was saved.
• Translated banners without `lang` attribute — screen readers pronounce Spanish copy with English phonetics.

How FlexyConsent Delivers Accessibility