EN 301 549 v4.1.1: Changes, WCAG 2.2 & Next Steps

EN 301 549 v4.1.1: What's Changed and How to Prepare

‍

EN 301 549 v4.1.1 was published on September 2, 2026, introducing an important update to Europe's accessibility standard for information and communication technology (ICT) products and services.

‍

For websites and digital documents, one of the most significant changes is the adoption of WCAG 2.2 in place of WCAG 2.1. The new edition also revises requirements relating to user preferences, real-time communication, and the relationship between the standard and the European Accessibility Act (EAA).

‍

But what does this mean for organizations responsible for digital accessibility? Does the publication immediately change their legal obligations? And what should website owners and digital teams do now?

‍

This guide explains the main changes in EN 301 549 v4.1.1, the distinction between publication and legal harmonization, and the practical steps organizations can take to prepare.

‍

In brief:

EN 301 549 v4.1.1 was published by ETSI on September 2, 2026.
It adopts WCAG 2.2 for web content, non-web documents, and non-web software.
It includes additional changes beyond WCAG, including updated user-preference and real-time communication requirements.
Publication alone does not establish that the new edition has become the harmonized legal reference.
Organizations can begin assessing their digital products against WCAG 2.2 while continuing to meet the requirements currently applicable to them.

‍

For the official technical requirements, consult the EN 301 549 v4.1.1 standard published by ETSI (PDF).

‍

What is EN 301 549?

‍

EN 301 549 is a European standard that specifies accessibility requirements for ICT products and services. It covers more than websites: its scope includes software, electronic documents, hardware, telecommunications, and other digital technologies.

‍

The standard is developed through European standardization organizations, including ETSI, CEN, and CENELEC.

‍

EN 301 549 is particularly relevant to two pieces of European accessibility legislation:

The Web Accessibility Directive (WAD): Directive (EU) 2016/2102, which concerns the accessibility of websites and mobile applications of public sector bodies.
The European Accessibility Act (EAA): Directive (EU) 2019/882, which establishes accessibility requirements for specified products and services.

‍

The standard helps translate accessibility objectives into technical requirements that organizations can assess and implement. For web content, it draws heavily on the Web Content Accessibility Guidelines (WCAG).

‍

However, EN 301 549 and WCAG are not interchangeable. EN 301 549 includes requirements beyond web content, while the applicable legal obligations depend on the relevant legislation, its scope, and its implementation.

‍

Useful references:

‍

What changed in EN 301 549 v4.1.1?

‍

The new edition introduces several important changes. For organizations primarily responsible for websites, web applications, and digital documents, the move to WCAG 2.2 is likely to be the most immediately relevant.

‍

However, the update is broader than a change in WCAG version.

‍

1. WCAG 2.2 becomes the reference for web accessibility requirements

‍

EN 301 549 v4.1.1 updates its web, non-web document, and non-web software requirements to reference WCAG 2.2.

‍

WCAG 2.2 extends WCAG 2.1 with additional success criteria designed to address accessibility barriers experienced by people with visual, physical, and cognitive disabilities, among others.

‍

For website owners, the most relevant new Level A and AA criteria include:

Focus Not Obscured (Minimum) — WCAG 2.4.11, Level AA: Keyboard focus must not be entirely hidden by author-created content, such as a sticky header or overlay.
Dragging Movements — WCAG 2.5.7, Level AA: Functionality that uses dragging must have an alternative single-pointer operation, unless an exception applies.
Target Size (Minimum) — WCAG 2.5.8, Level AA: Pointer targets must meet the minimum size requirement or qualify for an applicable exception.
Consistent Help — WCAG 3.2.6, Level A: Repeated help mechanisms must appear in a consistent relative order across pages.
Redundant Entry — WCAG 3.3.7, Level A: Information previously entered by or provided to the user should not need to be entered again in the same process, unless an exception applies.
Accessible Authentication (Minimum) — WCAG 3.3.8, Level AA: Authentication should not require a cognitive function test unless an applicable exception is satisfied.

These criteria can affect everyday website interactions. A floating support button might cover a focused link. A product gallery might require dragging without providing an alternative. A multi-step application could ask users to re-enter information already supplied.

‍

Each example represents a potential accessibility issue, not an automatic failure in every implementation. The precise requirements and exceptions are defined in the standard.

‍

The WCAG 2.2 specification also contains three additional Level AAA criteria, which should not be confused with the six new Level A and AA criteria listed above.

‍

Read the official WCAG 2.2 specification and the W3C's guide to what's new in WCAG 2.2.

‍

2. Updated requirements for user preferences

‍

EN 301 549 v4.1.1 revises requirements relating to user preferences across web pages, non-web documents, and software.

‍

The underlying principle is that digital products should better respect the accessibility preferences people rely on when using their devices and software.

‍

Depending on the product and applicable requirements, this can involve preferences such as text presentation, contrast, and other display or interaction settings.

‍

For website and software teams, this is a reminder to consider how interfaces behave when users rely on operating-system settings, browser features, or assistive technologies. Accessibility should not depend solely on whether a product looks correct under default settings.

‍

The relevant requirements appear in clauses 9.7, 10.7, and 11.7 of EN 301 549 v4.1.1. Their applicability depends on the type of product and the scope of the relevant clause.

‍

3. Revised requirements for real-time communication

‍

The new edition also updates requirements for ICT supporting real-time communication, including real-time text (RTT), voice, video, and related functionality.

‍

These changes are especially relevant to organizations developing or supplying telecommunications systems, communication clients, video-conferencing products, and contact-center solutions.

‍

The requirements cover areas such as the provision and display of real-time text, interoperability, and communication scenarios.

‍

Organizations working in these areas should review the applicable provisions directly rather than assuming that a website-focused WCAG assessment will cover their obligations.

‍

4. Clearer mapping to the European Accessibility Act

‍

EN 301 549 v4.1.1 introduces additional mapping between the standard's requirements and the European Accessibility Act.

‍

This is intended to help organizations understand how technical requirements relate to the accessibility requirements established by the Act.

‍

The mapping is useful when planning assessments and documenting evidence, but it should not be treated as a substitute for interpreting the legislation that applies to a particular product or service.

‍

5. Broader ICT requirements remain important

‍

EN 301 549 is not simply a list of website success criteria. It includes requirements that may apply to hardware, non-web software, electronic documents, authoring tools, and communication services.

‍

Consequently, the impact of the new edition depends on what an organization builds, supplies, or operates.

‍

For a company that manages a marketing website, the WCAG 2.2 changes may be the main starting point. For a provider of communication systems or specialized software, the relevant changes may be much broader.

‍

Review the full EN 301 549 v4.1.1 standard to determine which clauses are relevant to your products and services.

‍

Does EN 301 549 v4.1.1 immediately change legal requirements?

‍

No. Publication of a new edition and its formal citation as a harmonized standard are separate steps.

‍

EN 301 549 v4.1.1 was published in September 2026. However, the publication date alone does not mean that every organization subject to European accessibility legislation must immediately demonstrate conformance with this edition.

‍

For a harmonized standard to provide a presumption of conformity with the corresponding requirements of EU harmonization legislation, its reference must be published in the Official Journal of the European Union.

‍

The latest official reference I could verify for the web accessibility framework is EN 301 549 v3.2.1 (2021-03), listed in Commission Implementing Decision (EU) 2021/1339.

‍

Before publishing this article, check the current Official Journal references and applicable legislation for any updates concerning v4.1.1.

‍

Official sources:

‍

What does this mean for organizations subject to the EAA?

‍

Organizations should distinguish between the accessibility obligations already applicable to their products and services and the technical changes introduced by the new edition.

‍

The EAA applies to specified products and services within its scope, subject to the Directive's provisions and applicable national law. The Web Accessibility Directive has a different scope, focusing on public sector websites and mobile applications.

‍

Neither publication of EN 301 549 v4.1.1 nor the adoption of WCAG 2.2 automatically establishes the same legal obligation for every website in Europe.

‍

For an organization planning its accessibility work, the practical approach is to:

Identify the legislation and requirements that apply to its products and services today.
Continue meeting those requirements.
Assess the additional WCAG 2.2 criteria and other relevant changes in v4.1.1.
Review the official harmonization status and any applicable transition provisions.
Plan remediation and validation work based on the actual scope of the organization's digital products.

This approach supports preparation without confusing a technical update with a universal change in legal obligations.

‍

How should organizations prepare for EN 301 549 v4.1.1?

‍

Organizations do not need to wait for every legal and transition detail to be finalized before understanding the technical changes. Preparing early can help teams identify gaps, estimate remediation effort, and incorporate accessibility into their development processes.

‍

1. Establish your current accessibility baseline

‍

Start by understanding the current state of your website, web applications, and digital documents.

‍

Identify the pages and user journeys that matter most: account creation, login, search, forms, checkout, document access, and other important tasks.

‍

An initial accessibility assessment can help identify issues such as missing text alternatives, insufficient contrast, inaccessible form controls, and keyboard-navigation problems.

‍

Wawsome's Accessibility Checker can help teams identify automatically detectable accessibility issues and prioritize further investigation.

‍

Automated testing is a starting point, not proof of complete conformance. Some requirements need manual testing and human judgment.

‍

2. Review the new WCAG 2.2 criteria

‍

Compare your current accessibility requirements and testing process with WCAG 2.2.

‍

Pay particular attention to:

Keyboard focus that may be hidden behind sticky headers, footers, or dialogs.
Drag-and-drop interactions without alternative controls.
Small pointer targets and applicable exceptions.
Help mechanisms that change position or order between pages.
Multi-step forms that ask users to enter the same information repeatedly.
Authentication processes that create unnecessary cognitive barriers.

Test these interactions in context, including on mobile devices and in important user journeys.

‍

The W3C WCAG 2.2 documentation provides explanations and examples for individual success criteria.

‍

3. Prioritize fixes by impact and effort

‍

Not every issue has the same effect on users or the same remediation cost.

‍

Prioritize barriers that prevent people from completing essential tasks, especially where they affect multiple pages or reusable components.

‍

A focus problem in a shared navigation component, for example, may affect a large portion of a website. Fixing the underlying component can be more effective than applying separate workarounds to individual pages.

‍

Create a remediation plan that identifies the issue, affected user journey, responsible team, proposed fix, and validation method.

‍

4. Test beyond the automated scan

‍

Automated scanners can detect many programmatic issues, but they cannot reliably determine every aspect of accessibility.

‍

Manual testing should include keyboard navigation, visible focus, interaction behavior, zoom and text resizing, form validation, and appropriate assistive-technology testing.

‍

This is particularly important for WCAG 2.2 criteria that depend on how users interact with an interface or complete a task.

‍

For a more detailed explanation, read Wawsome's guide to accessibility audits, widgets, and monitoring.

‍

5. Integrate accessibility into ongoing website maintenance

‍

Accessibility is not a one-time project. Websites change as teams publish pages, introduce integrations, update forms, launch campaigns, and modify shared components.

‍

A website that was assessed several months ago may have developed new accessibility issues since then.

‍

Wawsome's Accessibility Monitor helps teams track automatically detectable issues over time and identify potential regressions as their websites change.

‍

Monitoring complements an initial assessment and manual testing; it does not replace them.

‍

6. Document your work and keep it up to date

‍

Maintain a record of assessments, identified issues, remediation decisions, validation results, and outstanding barriers.

‍

This gives development, product, legal, and accessibility teams a shared view of progress and helps them make informed decisions when standards or requirements change.

‍

Where applicable, review your accessibility statement and related documentation to ensure they accurately reflect the current status of your website and the assessment methods used.

‍

Wawsome also provides an accessibility statement guide to help organizations understand what an accessibility statement should contain.

‍

Can an accessibility widget make a website conform to EN 301 549?

‍

An accessibility widget can offer useful interface adjustments and help some visitors adapt their experience. However, a widget alone cannot establish that a website conforms to EN 301 549 or WCAG.

‍

The standard includes requirements relating to underlying code, document structure, keyboard operation, interaction behavior, and compatibility with assistive technologies. These cannot all be resolved by changing the appearance of a page.

‍

A more complete approach combines:

Automated accessibility testing to identify detectable issues.
Manual assessment to evaluate behavior and context.
Code and content remediation to address the underlying barriers.
Validation to confirm that fixes work as intended.
Ongoing monitoring to identify new detectable issues as the website changes.

Wawsome's Accessibility Widget, Accessibility Checker, and Accessibility Monitor support different parts of this process. They are complementary tools, not a substitute for a complete accessibility assessment.

‍

For an overview of how these approaches differ, see Accessibility Widget, Audit & Monitoring.

‍

FAQs about EN 301 549 v4.1.1

‍

What is EN 301 549 v4.1.1?

‍

EN 301 549 v4.1.1 is the September 2026 edition of the European standard for accessibility requirements for ICT products and services. It updates the requirements for web content, non-web documents, software, and other ICT areas.

‍

What is the main change in EN 301 549 v4.1.1?

‍

For websites and digital documents, one of the most significant changes is the adoption of WCAG 2.2. The edition also updates user-preference requirements, real-time communication requirements, and mapping to the European Accessibility Act.

‍

Does EN 301 549 v4.1.1 replace WCAG 2.1?

‍

The new edition references WCAG 2.2 for relevant web, non-web document, and non-web software requirements. However, the formal legal effect of the new edition depends on its harmonization status and the legislation applicable to the organization.

‍

Is EN 301 549 v4.1.1 already legally mandatory?

‍

Publication does not, by itself, make the new edition the harmonized reference under EU law. Organizations should verify the latest Official Journal references and the requirements applicable to their products and services before making compliance decisions.

‍

Does WCAG 2.2 include new Level AA requirements?

‍

Yes. WCAG 2.2 adds new Level A, AA, and AAA success criteria. Important additions at Level AA include Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum).

‍

Can an automated accessibility scanner test all EN 301 549 requirements?

‍

No. Automated tools can identify certain issues, but some requirements need manual testing, context-sensitive evaluation, and assistive-technology testing. The appropriate assessment depends on the product and the applicable clauses of the standard.

‍

How can organizations prepare for EN 301 549 v4.1.1?

‍

Organizations can review the new standard, compare their current testing process with WCAG 2.2, assess important user journeys, prioritize remediation, validate fixes manually, and establish ongoing monitoring. They should also verify the legal requirements and transition provisions that apply to them.

‍

Start preparing for the next stage of digital accessibility

‍

EN 301 549 v4.1.1 is an important development for organizations building and maintaining accessible digital products. Its adoption of WCAG 2.2 gives website teams a clearer technical direction, while its wider changes matter to organizations responsible for software, documents, communication systems, and other ICT products.

‍

The most useful next step is to understand your current accessibility status, identify gaps against the relevant requirements, and create a practical remediation plan.

‍

Wawsome can help you start that process with automated accessibility checks and ongoing monitoring.

‍

An informed, ongoing approach helps organizations improve accessibility today while preparing for evolving standards and requirements.