WCAG 2.2 vs EN 301 549: What's the Difference?

If you're working on accessibility compliance in Europe, you'll encounter two standards constantly: WCAG and EN 301 549. They're related, they overlap significantly, but they're not the same thing - and knowing the difference matters for EAA compliance.

The short version

WCAG (Web Content Accessibility Guidelines) is an international standard from the W3C that defines how to make web content accessible. The current version is WCAG 2.2.

EN 301 549 is a European standard that defines accessibility requirements for ICT (Information and Communications Technology) products and services. It incorporates WCAG but adds requirements for non-web ICT like software, hardware, documents, and more.

Think of it this way: WCAG is about web content. EN 301 549 is about everything digital - and it uses WCAG for the web content part.

What is WCAG?

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium (W3C) through their Web Accessibility Initiative (WAI). WCAG has gone through several versions:

• - **WCAG 1.0** (1999) - the original, now obsolete
• - **WCAG 2.0** (2008) - introduced the four principles (Perceivable, Operable, Understandable, Robust) and three conformance levels (A, AA, AAA)
• - **WCAG 2.1** (2018) - added 17 new success criteria, mainly for mobile and cognitive accessibility
• - **WCAG 2.2** (2023) - added 9 more success criteria, including Focus Not Obscured, Target Size, and Accessible Authentication

WCAG 2.1 Level AA is the baseline referenced by most accessibility laws worldwide, including the EAA (via EN 301 549). WCAG 2.2 extends this with additional criteria that improve the user experience but aren't yet universally mandated.

Each version is backward-compatible: a site conforming to WCAG 2.2 AA also conforms to WCAG 2.1 AA and WCAG 2.0 AA.

What is EN 301 549?

EN 301 549 is a harmonised European standard titled "Accessibility requirements for ICT products and services." It's maintained by ETSI (European Telecommunications Standards Institute), CEN, and CENELEC.

The current version is EN 301 549 V3.2.1 (2021), with an update to V4.1.1 expected to reference WCAG 2.2.

EN 301 549 was originally created to support EU public procurement of accessible ICT. With the EAA, it's now the reference standard for private sector compliance as well.

Structure of EN 301 549

EN 301 549 is organised into clauses covering different types of ICT:

• - **Clause 5** - Generic requirements (closed functionality, biometrics, etc.)
• - **Clause 6** - ICT with two-way voice communication (VoIP, video calls)
• - **Clause 7** - ICT with video capabilities (captions, audio description)
• - **Clause 8** - Hardware (physical design, connections, controls)
• - **Clause 9** - Web content (this is where WCAG lives)
• - **Clause 10** - Non-web documents (PDFs, Word, spreadsheets)
• - **Clause 11** - Software (native apps, desktop applications)
• - **Clause 12** - Documentation and support services
• - **Clause 13** - ICT providing relay or emergency services
• - **Clause 14** - Conformance

How they relate

Clause 9 of EN 301 549 directly incorporates WCAG 2.1 Level AA. Every WCAG 2.1 Level A and AA success criterion is mapped to a corresponding requirement in EN 301 549 Clause 9. The requirement numbers even follow a predictable pattern - EN 301 549 requirement 9.1.1.1 maps to WCAG success criterion 1.1.1.

So for web content, complying with WCAG 2.1 Level AA means you've met the Clause 9 requirements of EN 301 549. They're functionally equivalent for websites.

But EN 301 549 goes further.

What EN 301 549 adds beyond WCAG

If you only do web development and your product is a website, the gap between WCAG and EN 301 549 is small. But for many businesses, EN 301 549 adds significant requirements:

Non-web documents (Clause 10)

If your service includes downloadable PDFs, Word documents, spreadsheets, or presentations, these must also be accessible. Clause 10 maps WCAG success criteria to non-web documents, requiring:

• - Proper heading structure in PDFs
• - Tagged content for screen readers
• - Accessible tables with headers
• - Text alternatives for images in documents
• - Readable, reflowable content

Many businesses overlook this. Your website might be fully WCAG-compliant, but if your terms of service PDF, product catalogues, or invoices are inaccessible, you're not meeting EN 301 549.

Native applications (Clause 11)

Mobile apps and desktop software have their own set of requirements in Clause 11. These map WCAG concepts to non-web software, covering:

• - Platform accessibility API support (using native UI components correctly)
• - Programmatic access to names, roles, and states of controls
• - Focus order and navigation within the application
• - Accessibility of custom controls
• - Support for platform accessibility settings (text size, high contrast, etc.)

If you have a mobile app alongside your website, both must be accessible - and the app requirements go beyond what WCAG alone specifies.

Hardware and physical interfaces (Clause 8)

If your product includes hardware (kiosks, terminals, payment devices), Clause 8 adds requirements for:

• - Operable parts that can be used with one hand and without tight grasping
• - Keys and controls that are tactilely discernible
• - Visual, auditory, and tactile indicators for status
• - Connection points for assistive technology

This is entirely outside WCAG's scope.

Communication services (Clauses 6 and 7)

If your service includes video calling, VoIP, or streaming video, additional requirements apply:

• - Real-time text (RTT) support alongside voice
• - Caption synchronisation within 100ms
• - Audio description support
• - Sign language video quality requirements

Support and documentation (Clause 12)

Your support channels and product documentation must also be accessible:

• - Help desks must accommodate users with disabilities
• - Documentation must describe accessibility features
• - Support must be available through accessible communication channels

Which one should you reference for EAA compliance?

For EAA compliance, EN 301 549 is the reference standard. The EAA directive states that products and services are presumed to comply if they meet the relevant harmonised European standard - which is EN 301 549.

In practice:

• - **If you only have a website** - achieving WCAG 2.1 Level AA conformance covers the EN 301 549 Clause 9 requirements. But review Clause 10 if you have downloadable documents and Clause 12 for your support channels.
• - **If you have a website and mobile app** - you need WCAG 2.1 AA for the website (Clause 9) plus Clause 11 requirements for the app.
• - **If you have hardware products** - you need the full scope of EN 301 549, including Clause 8.

When talking to your development team, WCAG is the practical standard to work with for web content. When talking to legal or compliance teams, reference EN 301 549.

WCAG 2.2: do you need to comply?

The current version of EN 301 549 (V3.2.1) references WCAG 2.1, not WCAG 2.2. So strictly speaking, the EAA requires WCAG 2.1 Level AA compliance for web content.

However:

• - EN 301 549 V4.1.1 is expected to update the reference to WCAG 2.2
• - WCAG 2.2 is backward-compatible, so meeting 2.2 automatically meets 2.1
• - Several WCAG 2.2 success criteria address common usability issues (like [Focus Not Obscured](/blog/what-is-focus-not-obscured-wcag-2-4-11)) that are worth fixing regardless

Our recommendation: target WCAG 2.2 Level AA. It's a superset of 2.1, future-proofs your compliance, and the additional criteria genuinely improve the user experience.

Practical implications for your team

For web developers

Focus on WCAG 2.1 Level AA (or 2.2 to future-proof). Use automated tools like Lumi to catch issues during development, and integrate scanning into your CI/CD pipeline. The WCAG success criteria map directly to testable requirements.

For content teams

Remember that EN 301 549 covers non-web documents. Every PDF, every downloadable guide, every email template needs to be accessible. Use your authoring tool's built-in accessibility checker and ensure documents are properly tagged.

For product managers

Scope your compliance work against the full EN 301 549, not just WCAG. If you have a mobile app, downloadable documents, video content, or support channels, each has specific requirements beyond web content.

For compliance officers

Reference EN 301 549 in your compliance documentation and accessibility statements. Note the specific clauses that apply to your product or service. Our accessibility statement generator creates a statement that references the correct standards.

Summary

| | WCAG 2.1/2.2 | EN 301 549 | |---|---|---| | Scope | Web content | All ICT (web, apps, documents, hardware, services) | | Published by | W3C (international) | ETSI/CEN/CENELEC (European) | | Legal basis | Referenced by many laws worldwide | Referenced by EAA and EU procurement | | Web requirements | Directly defined | Incorporates WCAG for web content | | Non-web requirements | Not covered | Comprehensive coverage |

For most businesses, starting with WCAG 2.1 AA for your website is the right first step. Use Lumi to scan your site and identify issues, then expand your scope to cover the full EN 301 549 requirements for your specific product or service.