Back to Blog

WCAG Guidelines

WCAG 2.1 AA vs EN 301 549 vs EAA: Which Standard Applies to You? (2026 Guide)

EU businesses confuse WCAG, EN 301 549, and the EAA. Here is the simple hierarchy, who needs which, and how the three standards stack.

7 May 2026

Updated 16 May 2026

11 min read

Ravid, Webply

The three things in plain English

If you have ever tried to read accessibility legislation, you have probably encountered all three of these acronyms in one paragraph and walked away unsure which one to actually follow. The short answer is: all three, and they wrap each other.

WCAG (Web Content Accessibility Guidelines) is a technical specification published by the World Wide Web Consortium's Web Accessibility Initiative (W3C WAI). It is not a law. It is a checklist of things web content should do — alt text on images, sufficient colour contrast, keyboard operability, semantic markup, and so on. Governments and standards bodies reference it, but WCAG itself has no legal force.

EN 301 549 is a European harmonised standard published jointly by ETSI, CEN, and CENELEC. It tells you what an accessible piece of ICT (information and communication technology) looks like in the European context. For web content specifically, EN 301 549 adopts WCAG 2.1 Level AA in full — meaning every WCAG 2.1 AA criterion is also an EN 301 549 requirement. It then adds extra requirements that WCAG does not cover: documentation, support services, hardware accessibility, biometric authentication, two-way voice, video, and so on.

The EAA (European Accessibility Act) is a binding EU directive — Directive (EU) 2019/882. It is the legal layer. The EAA tells you which products and services have to be accessible, who has to make them accessible, and what happens if you do not. The EAA itself does not list the technical requirements — it points to EN 301 549 (and equivalents) as the way to demonstrate compliance.

So when someone asks "what standard do I follow", the correct answer is: the EAA tells you whether you must comply, EN 301 549 tells you what technical requirements apply to you, and WCAG tells you specifically how to meet the web part of EN 301 549.

The hierarchy, visualised

In practice, you read this stack from the bottom up when you are doing the work, and from the top down when you are figuring out whether you have to do the work at all.

WCAG 2.1 AA: what it actually covers

WCAG is built around four high-level principles, abbreviated POUR:

• Perceivable — content must be presentable to users in ways they can perceive (text alternatives for images, captions for video, sufficient colour contrast).
• Operable — interface components must be operable (keyboard accessible, no time limits that cannot be extended, no seizure-inducing content).
• Understandable — content and operation must be understandable (predictable navigation, input assistance, readable language).
• Robust — content must be robust enough to be interpreted by user agents including assistive technologies (valid markup, ARIA used correctly).

Within those four principles, WCAG defines individual success criteria, each tagged at one of three levels:

• Level A — the absolute minimum. Failing A means the content is genuinely unusable for some people.
• Level AA — the legal target almost everywhere in the world. Includes A.
• Level AAA — the highest level. Generally only applicable to specialist content; most general websites cannot reach AAA without trade-offs.

WCAG 2.1 was published in June 2018 and has 50 success criteria (25 A, 13 AA, 12 AAA when counting the Level AA target as A+AA = 38 criteria). WCAG 2.2 was published in October 2023 and adds nine new criteria — focus appearance, dragging movements, target size, accessible authentication, and consistent help being the most-discussed.

For most regulators in 2026, including the EAA, WCAG 2.1 Level AA is the legal target. WCAG 2.2 is recommended best practice, especially for new builds, but is not yet referenced in EN 301 549's current published version.

EN 301 549: how it extends WCAG

EN 301 549 covers more than just websites. WCAG was written for web content; EN 301 549 is written for "ICT" — anything from a kiosk in an airport to a smart TV remote control to the documentation that ships with a piece of consumer electronics.

Here is what EN 301 549 adds to a clean WCAG 2.1 AA pass, by chapter:

• Chapter 5 — generic requirements applying to any ICT (e.g. usable without vision, hearing, fine motor control, etc.).
• Chapter 6 — two-way voice communication (telephony).
• Chapter 7 — video that contains audio.
• Chapter 8 — hardware (keyboard interaction, tactile controls, low-force operation).
• Chapter 9 — web content. This is where WCAG 2.1 AA lives in full.
• Chapter 10 — non-web documents (PDFs, Word, e-books).
• Chapter 11 — software (native applications).
• Chapter 12 — documentation and support services (manuals, help desks, training material).
• Chapter 13 — ICT providing relay services or emergency comms.

For a typical SMB running a website + a help centre + some downloadable PDFs, chapters 9 (web), 10 (PDFs), and 12 (support) are the relevant ones. The big practical addition over plain WCAG is chapter 12: your support documentation and your customer service channels also have to be accessible — phone support that is text-only, manuals available in accessible electronic format, and so on.

For a fuller picture of what enforcement looks like in practice, see our breakdown of country-by-country EAA fines or browse the EAA Fines by Country reference for all 27 member states.

The EAA: scope and exemptions

The EAA covers two categories of obligation:

Products — physical or digital products placed on the EU market. The Annex lists them: computer hardware, self-service terminals (ATMs, ticket machines), consumer telecom terminals (phones), consumer audio-visual terminals (set-top boxes, TVs), e-readers.

Services — the more relevant category for most of our readers:

• Electronic communications services for consumers (mobile, internet, VoIP).
• Services providing access to audio-visual media services (websites, apps, set-top boxes that let you watch).
• Air, bus, rail, and waterborne passenger transport services — the websites, mobile apps, e-tickets, self-service kiosks.
• Consumer banking services — accounts, loans, payments, the mobile app.
• E-books and dedicated software for them.
• E-commerce services — and this is the big one, because almost every online business that sells to consumers in the EU falls under it.

Exemptions are narrower than people often hope:

• Microenterprise exemption (services only) — companies with fewer than 10 employees AND less than €2M annual turnover are exempt from the SERVICE obligations. Product obligations still apply. National laws that pre-date the EAA may also still apply.
• Disproportionate burden — you can argue that meeting a specific requirement would impose a disproportionate burden, but you must document the assessment and reassess every five years. It is not a free pass.
• Fundamental alteration — if compliance would fundamentally alter the nature of the product or service, that specific requirement does not apply. Again, the bar is high and must be documented.

Existing services have a longer grace period than products (until 28 June 2030 for some pre-existing service contracts), but new services and new products had to comply by 28 June 2025.

"Am I subject to the EAA?" — quick decision flow

For most B2C operators in the EU in 2026: yes, you are in scope. The serious exception is genuinely tiny operators or pure B2B SaaS that does not serve consumers.

Common confusions, briefly

"WCAG 2.2 is the new standard, so I need 2.2." — Not yet, legally. EAA references EN 301 549, which is currently aligned with WCAG 2.1 AA. WCAG 2.2 will likely be folded into a future revision of EN 301 549, but in 2026 it is best-practice rather than a legal requirement.

"I need AAA." — Almost never. AAA is reserved for content specifically targeted at users with disabilities. General consumer sites cannot meet AAA without trade-offs that hurt usability for everyone else.

"Public sector and private sector follow different rules." — Partially true historically. In EU public sector, the Web Accessibility Directive (Directive (EU) 2016/2102) has required accessibility of government websites since 2018. EAA extends similar requirements to private sector for the listed product/service categories. The technical baseline is the same: EN 301 549.

"GDPR-compliant means accessibility-compliant." — No. GDPR governs personal data; accessibility law governs how content is presented. The two regimes are independent — being one does not imply the other.

"My platform provider (Shopify, Webflow, etc.) handles accessibility." — Partially. Platforms provide accessible building blocks; how you assemble them, what content you put in, your custom styles, your third-party integrations, and your forms are all your responsibility. A clean platform default does not survive a custom homepage hero with low-contrast text and no alt attributes.

What to do this week

If you are reading this and not sure where you stand, here is the cheapest first step:

1. Run an automated WCAG 2.1 AA scan across your real templates — homepage, product/category pages, checkout, account, contact, footer.
2. Read the country-specific fines in our EAA fines breakdown for the markets you actually sell into.
3. Write a short accessibility statement — your tooling, your conformance level, who to contact for accessibility issues. This alone closes a real legal gap (France specifically fines for missing it).
4. Decide whether your site needs a deep manual audit or whether the automated findings are enough for now. For most SMBs, automated catches 30–40% of issues but it catches the load-bearing ones that get you fined.