WCAG vs GDPR: Two Different Legal Obligations for Websites

What WCAG Is and Where It Comes From

WCAG — the Web Content Accessibility Guidelines — is a technical standard published by the W3C (World Wide Web Consortium). It defines how web content should be designed to be perceivable, operable, understandable, and robust for users with disabilities. WCAG itself is not a law. It becomes legally binding when referenced by accessibility legislation — which many jurisdictions have now done.

In the European Union, WCAG 2.1 AA is the technical standard referenced by the Web Accessibility Directive (Directive 2016/2102) and the European Accessibility Act (EAA, Directive 2019/882). The Web Accessibility Directive applies to public sector websites and mobile apps. The EAA extends accessibility obligations to a broader range of private sector services, with EU member state implementation deadlines from 2025 to 2030 depending on sector.

In the UK, accessibility obligations derive from the Equality Act 2010 (reasonable adjustments for disabled users) and the Public Sector Bodies Accessibility Regulations 2018. In the United States, WCAG 2.1 AA has been adopted as the standard for Title II ADA compliance in the DOJ's 2024 final rule for state and local government websites. The practical consequence is that WCAG is now effectively the global baseline standard for digital accessibility, enforced through different legal instruments in different jurisdictions.

What GDPR Is and Where It Comes From

GDPR — the General Data Protection Regulation (EU) 2016/679 — is a data protection law. It governs the collection, processing, storage, and transfer of personal data relating to individuals located in the EU. GDPR has no accessibility requirements. It does not specify how websites should be designed to be usable by disabled users. Its requirements are about the lawfulness, fairness, and transparency of personal data processing — not the usability of the interface through which that processing is disclosed.

The ePrivacy Directive (2002/58/EC), which governs cookie and tracking consent specifically, similarly has no accessibility requirements. It requires that consent be informed, specific, and freely given — but the means of obtaining that consent (the banner design) is not regulated by ePrivacy except insofar as the design must allow genuine free choice. A banner could technically satisfy all GDPR and ePrivacy consent requirements while being completely unusable by a screen reader user.

GDPR enforcement is handled by national Data Protection Authorities (DPAs), funded by member state governments, and focused on data protection outcomes. Accessibility enforcement — under the EAA, Web Accessibility Directive, or national equality laws — is handled by entirely different regulatory bodies. In the UK, accessibility complaints go to the Equality and Human Rights Commission or are pursued through employment tribunals. In the EU, the EAA is enforced by market surveillance authorities, not DPAs.

Where WCAG and GDPR Actually Overlap

The only place where WCAG and GDPR requirements genuinely converge is in the design and implementation of consent banners. GDPR requires that consent be freely given and that rejection be as easy as acceptance. WCAG 2.1 requires that interactive elements be operable by keyboard users (Success Criterion 2.1.1), that focus order be logical (SC 2.4.3), and that no component creates a keyboard trap (SC 2.1.2). A consent banner that is visually accessible but cannot be dismissed by a keyboard user simultaneously fails both WCAG 2.1 and the 'freely given' requirement under GDPR.

Colour contrast is another point of intersection. WCAG 2.1 SC 1.4.3 requires that text have a contrast ratio of at least 4.5:1 against its background. A consent banner with a grey 'Reject' button on a white background may fail this contrast requirement. It may simultaneously fail GDPR's freely-given test if the low contrast effectively discourages users from selecting the reject option — a finding that some regulators have made in dark pattern investigations.

Focus management for modal consent banners is a shared concern. WCAG 2.1 SC 2.1.2 prohibits keyboard traps — situations where a keyboard user navigates into a component and cannot navigate back out. A consent banner implemented as a modal that traps keyboard focus until the user accepts (but not if they try to close without consenting) is simultaneously a WCAG failure and potentially a GDPR freely-given failure, depending on whether the close action triggers acceptance.

The European Accessibility Act and Consent Mechanisms

The European Accessibility Act came into effect for new products and services in EU member states from June 2025. It covers a wide range of digital services including e-commerce, banking, transport booking, and streaming services — the same sectors most heavily regulated for GDPR cookie consent. The EAA does not explicitly address consent banners, but it requires that covered services be accessible according to WCAG-equivalent standards, which means all interactive elements of those services — including consent interfaces — must meet WCAG 2.1 AA.

The practical implication is that organisations subject to the EAA must audit their consent banners not only for GDPR validity but for WCAG 2.1 AA compliance. This is a new dual-compliance requirement that many legal and compliance teams have not yet fully integrated. A consent banner can be GDPR-valid — correctly structured, with equal-prominence reject option — while still being inaccessible to a screen reader or keyboard-only user.

National enforcement of the EAA varies across member states. Some countries have designated specific market surveillance authorities; others have assigned responsibility to existing consumer protection or communications regulators. The enforcement landscape for the EAA is significantly less developed than for GDPR as of 2026, but the legal obligation is present and penalties under the EAA can reach significant amounts under national implementing legislation.

What ConsentLens Audits — and What It Does Not

ConsentLens is a GDPR and ePrivacy compliance scanner. It evaluates cookie consent mechanisms, tracker behaviour, pre-consent tracking, and consent banner structure for GDPR and ePrivacy compliance. It does not perform WCAG audits. The scanner does not evaluate colour contrast, ARIA attributes, keyboard navigation, focus management, screen reader compatibility, or any other accessibility criterion.

This scope limitation is intentional. WCAG auditing requires a fundamentally different technical approach — it involves DOM structure analysis, automated accessibility rule engines (such as axe-core), and manual testing with assistive technologies. Combining GDPR scanning with WCAG auditing in a single automated tool would produce a lower-quality output for both disciplines. ConsentLens's value lies in the depth of its GDPR analysis, not in covering all possible compliance dimensions.

If your organisation needs WCAG compliance assessment alongside GDPR scanning, we recommend pairing ConsentLens scans with a dedicated accessibility testing tool such as axe DevTools, Deque's managed accessibility platform, or a manual expert audit from an accessibility specialist. The two assessments are complementary and address different legal obligations — neither replaces the other.

Building Consent Banners That Satisfy Both Frameworks

Designing a consent banner that satisfies both GDPR and WCAG 2.1 AA is achievable with explicit attention to both frameworks' requirements. For GDPR: ensure the reject option is offered at the first interaction layer, at equal visual weight to accept, with no extra navigation required. For WCAG: ensure all buttons meet contrast requirements (4.5:1 minimum), the banner is navigable by keyboard in logical order, focus is trapped within the modal but escapable via a keyboard-accessible dismiss mechanism, and all interactive elements have accessible names for screen readers.

The most common failure mode in combined GDPR/WCAG compliance for consent banners is treating the two as sequential rather than simultaneous requirements. A team satisfies GDPR by adding a reject button, then discovers the banner fails WCAG because the reject button has insufficient contrast. Then they fix the contrast but inadvertently move the reject button to a less prominent position in the layout — re-introducing the GDPR freely-given failure. The correct approach is to design for both requirements from the outset with explicit acceptance criteria for each.

Accessible consent design is also good UX design. Banners that are clearly labelled, keyboard-navigable, and unambiguous in their options consistently show higher genuine consent rates than dark-pattern banners that confuse or obstruct users. A clearly presented choice between accept and reject, where both options are equally visible and equally easy to activate, is the legal requirement and the most honest representation of what you are asking users to agree to.

Practical Steps for Dual Compliance

Start with GDPR compliance for your consent banner: verify that a reject option exists at equal visual prominence on the first layer, confirm no trackers fire before consent, and check that consent signals are correctly passed to your tag manager or direct script implementations. ConsentLens can assess all of these. Run a scan of your domain and review the consent-related issues in the report.

Then assess WCAG compliance separately. Use an automated accessibility checker (axe, WAVE, or Lighthouse accessibility audit) on the consent banner in its open state. Verify: colour contrast of all text elements, keyboard operability of all buttons, logical focus order, no keyboard trap that prevents escape without acceptance, and appropriate ARIA roles for modal dialogs. Pay particular attention to the reject button — it is the element most commonly affected by dark pattern design choices that also create accessibility failures.

Document both compliance assessments separately. GDPR compliance documentation serves a different audience and regulatory body than WCAG accessibility statements. In the EU, public sector sites must publish an accessibility statement under the Web Accessibility Directive. This statement is not the same as a GDPR privacy notice or a cookie policy — they are legally distinct documents with different required content and different update obligations.

Frequently Asked Questions

Related guides