The Coming Shift: EN 301 549 and WCAG 2.2

For organizations operating within the European Union and adhering to the European Accessibility Act, the current standard is EN 301 549 V3.2.1 (2021-03), which incorporates WCAG 2.1. This will change. The European Committee for Standardization (ETSI) is slated to update EN 301 549 to align with WCAG 2.2. While the ETSI publication date is a key indicator, the true legal obligation begins when the new standard is formally cited in the Official Journal of the European Union. This citation is anticipated to occur near the end of 2026.

The transition to WCAG 2.2 introduces several key changes, including new success criteria, modifications to existing ones, and the removal of a specific requirement. Understanding these shifts is crucial for maintaining compliance and ensuring digital inclusivity.

Key Dates and Milestones

The timeline for the EN 301 549 update is driven by ETSI's publication process and the subsequent EU legal adoption. While the exact date the standard becomes legally binding is when it's cited in the Official Journal, the ETSI milestones provide a clear roadmap.

The public-enquiry draft for V4.1.0, which is expected to incorporate WCAG 2.2, was completed in November 2025. The final draft was completed in June 2026. The formal publication of EN 301 549 V4.1.0 is expected in December 2026. Following publication, the standard must be officially cited in the Official Journal of the EU to become a legal requirement. This citation is anticipated around the end of 2026.

This means that organizations have a window of opportunity to prepare for the changes. Proactive adaptation will be key to a smooth transition.

What Changes with WCAG 2.2?

WCAG 2.2 introduces nine new success criteria, modifies some existing ones, and importantly, removes one criterion that is now considered obsolete. The six criteria that are most impactful for compliance and development include:

  • 2.4.7 Focus Visible (Level AA): This criterion, already part of WCAG 2.1, remains and is emphasized. It requires that any user interface component that can receive keyboard focus must have a visible focus indicator. This ensures keyboard users can easily track their navigation.
  • 2.5.3 Label in Name (Level A): This new criterion requires that the name of a user interface component includes the text that is visible to the user as the component's label. This improves clarity and predictability for screen reader users.
  • 2.5.4 Drag and Drop (Level AA): This new criterion addresses the accessibility of drag-and-drop functionality. It requires that an alternative mechanism is available for performing drag-and-drop actions, such as a button or link, to accommodate users who cannot perform such gestures.
  • 2.5.6 Concurrent Input Mechanisms (Level AAA): This new criterion requires that functionality is not provided through touch and that no keyboard operating mechanism is blocked by the presence of another on the page. This is a Level AAA criterion, meaning it is a best practice rather than a strict legal requirement for most.
  • 3.2.6 Consistent Help (Level A): This new criterion requires that identification, labels, and instructions for form controls are consistent and available when needed. This is particularly relevant for user support and guidance.
  • 3.3.7 Redundant Entry (Level A): This new criterion prohibits requiring users to re-enter information that has already been provided in another form within the same session. This significantly improves the user experience, especially for complex forms.

The inclusion of these new criteria means that digital products and services will need to be re-evaluated against a more stringent set of accessibility requirements.

The Disappearing Requirement: 4.1.1 Parsing

One of the most significant changes in WCAG 2.2 is the removal of success criterion 4.1.1 Parsing. This criterion, which was at Level A, stated that content must be correctly parsed using the grammar that was valid for the specific markup language. While seemingly technical, its removal is driven by the fact that modern browsers are highly forgiving and can typically render content even if it contains parsing errors. The focus has shifted to actual user experience and perceivable, operable, testable, and robust content, rather than strict adherence to parsing rules that have become less critical due to browser advancements.

This removal simplifies compliance in one area but does not diminish the importance of overall code quality and semantic correctness, which still contribute to robust accessibility.

What This Means for Stakeholders

For developers, this update necessitates a thorough review of existing codebases and development practices. New testing protocols and design considerations will be required to meet the updated success criteria. The focus on focus visibility, clear labeling, and alternative input mechanisms will demand careful attention during the design and implementation phases.

For product managers and designers, understanding these changes is vital for setting project requirements and timelines. Ensuring that accessibility is integrated from the outset, rather than being an afterthought, will be critical for compliance and user satisfaction. The new criteria will influence UI/UX design, particularly concerning interactive elements and user guidance.

For businesses, the shift to WCAG 2.2 means reassessing their digital accessibility strategy. Compliance with EN 301 549 is not just a legal obligation but a commitment to inclusivity. Organizations that proactively adapt their websites, applications, and digital services will be better positioned to serve a wider audience and avoid potential legal challenges.

The transition from WCAG 2.1 to 2.2 within EN 301 549 is a natural evolution of digital accessibility standards. By understanding the new criteria and the revised approach to parsing, stakeholders can navigate this change effectively and ensure their digital offerings are accessible to all users.