EN 301 549 V4.1.1: Preparing Your Test Profile for WCAG 2.2

What V4.1.1 changes in the standard

The new edition was adopted on 24 August 2026 (ETSI) and published in September 2026 (AccessibleEU). For websites, it brings three content changes that AccessibleEU sums up in one sentence: six new requirements from WCAG 2.2, the removal of the obsolete 4.1.1 Parsing criterion, and a requirement to better respect users’ accessibility preferences (AccessibleEU).

• Six new A/AA requirements: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size, 3.2.6 Consistent Help, 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication. In the standard they appear as clauses 9.2.4.11 to 9.3.3.8 (ETSI). Compared with WCAG 2.1, WCAG 2.2 adds nine success criteria in total (W3C); the standard takes over those at Levels A and AA.
• 4.1.1 Parsing is gone: Clause 9.4.1.1 is void in V4.1.1, whereas earlier editions referenced criterion 4.1.1 from WCAG 2.0 and 2.1 at this point (ETSI). The W3C removed it from WCAG 2.2 because it no longer has any utility (W3C).
• User preferences for web pages: Clause 9.7 is new. A web page must not block the browser’s modes of operation that present it according to the user’s preference settings, and must not explicitly override documented platform accessibility features, unless this is essential to the information or function of the page (ETSI). As an example, the standard names the CSS property forced-color-adjust. V3.2.1 covered user preferences only for software (clause 11.7).
• Link to the European Accessibility Act: V4.1.1 is the first edition of the standard developed specifically with the European Accessibility Act in mind (AccessibleEU). A new Annex ZB maps its requirements to the essential requirements of Directive (EU) 2019/882 (ETSI).

What the individual criteria require and whom they help is explained by the W3C in its overview of what is new in WCAG 2.2 (W3C). This article deals with a different question: what does the new edition mean for the ongoing testing of a website while it is not yet legally effective?

What applies until the citation in the Official Journal

A harmonized standard does not take effect through its publication but through its reference in the Official Journal. Germany’s Accessibility Strengthening Act (BFSG) expressly ties the presumption that a product or service meets the requirements to harmonized standards whose references have been published in the Official Journal of the European Union (BFSG). The same mechanism appears in Article 15 of Directive (EU) 2019/882 (EAA) and, for public sector websites, in Article 6 of Directive (EU) 2016/2102 (WAD) as well as in Section 3(2) of the German Barrier-Free Information Technology Ordinance (BITV 2.0). The Commission puts it this way in one of its implementing decisions: compliance with a harmonized standard confers the presumption of conformity from the date its reference is published in the Official Journal (European Commission).

For V4.1.1, this step is still pending. AccessibleEU, the European Commission’s accessibility resource center, puts it like this: until the Commission formally cites EN 301 549 V4.1.1 in the Official Journal, V3.2.1 from 2021 remains the current reference, and that edition is based on WCAG 2.1 Level AA (AccessibleEU). The standard states it from its own perspective: only once it is cited in the Official Journal under Directive (EU) 2019/882 does compliance with its normative clauses confer a presumption of conformity (ETSI). Once that has happened, the presumption applies, according to AccessibleEU, to both the European Accessibility Act and the Web Accessibility Directive (AccessibleEU).

V3.2.1 has been cited since Implementing Decision (EU) 2021/1339 of 11 August 2021, under Directive (EU) 2016/2102 on public sector websites (European Commission). AccessibleEU names no date for the citation of the new edition, and it states explicitly that no new compliance deadline is linked to the publication. Dates circulating online come from secondary sources. The dates in the front matter of the standard are something else: national standards bodies must announce the edition by 30 November 2026 and publish or endorse it as a national standard by 31 May 2027, and conflicting national standards are to be withdrawn by 31 May 2028 (ETSI). These deadlines have nothing to do with the presumption of conformity.

Why WCAG 2.2 belongs in the test profile now

Three reasons speak for switching before the citation. First, WCAG 2.2 includes the older version: sites that conform to WCAG 2.2 also conform to WCAG 2.1 (W3C). The standard records the same relationship in its clauses. Conformance with WCAG 2.1 Level AA is equivalent to all clauses 9.1 to 9.4 except the six new ones (ETSI). A profile set to WCAG 2.2 therefore fully covers today’s reference and also shows what would be missing after the citation.

Second, the responsible W3C working group recommends adopting WCAG 2.2 as the new conformance target, even where formal obligations still mention earlier versions (W3C). In its announcement, AccessibleEU likewise advises organizations to review websites and digital documents against WCAG 2.2 now and to update testing processes and audit checklists (AccessibleEU).

Third, the BFSG requires service providers to take due account of changes to the harmonized standards referred to in their declaration of conformity (BFSG). That is not a deadline, but it is a mandate to follow developments. A test profile that distinguishes both editions is the right tool for this.

Which of the six new criteria a machine can test

The assessment is narrow. In version 4.12, the open-source axe-core engine has exactly one rule for the new A/AA criteria: target-size for 2.5.8 Target Size (axe-core). That rule is also disabled by default. The rule overview says the WCAG 2.2 rules stay disabled until WCAG 2.2 is more widely adopted and required (axe-core). A tool that runs axe-core with its default settings therefore does not test 2.5.8 at all.

In the XICTRAQ® test profile, the rule is switched on. The accessibility scan calls axe-core with the tags for WCAG 2.0, 2.1 and 2.2 at Levels A and AA, so target-size runs in every pass. The other five new criteria remain manual work. The accessibility check feature page explicitly lists Consistent Help, Redundant Entry and Accessible Authentication as manual review items. The same applies to 2.4.11 and 2.5.7: both depend on the interplay of focus, layout and interaction, and no rule in axe-core carries a tag for either criterion.

// Test profile: WCAG 2.0, 2.1 and 2.2, Level A and AA each
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22a', 'wcag22aa'])
  .analyze();

// results.violations  -> violations
// results.incomplete  -> cannot be decided reliably, review manually
// results.passes      -> passed rules

What the target size rule covers

The criterion requires a target size of at least 24 by 24 CSS pixels for pointer inputs, but lists five exceptions: sufficient spacing, an equivalent second control, targets within a sentence, sizes determined by the browser, and cases where a particular presentation is essential or legally required (W3C). A rule can detect whether a link sits inside running text. Whether the same page offers an equivalent second control often eludes it. axe-core therefore runs target-size with both result types, as a failure and as an item that needs review (axe-core). In the report, the uncertain cases belong on the manual list, not in the trash.

The opposite direction belongs in the profile too. axe-core lists the rules for 4.1.1 Parsing as deprecated, tagged wcag2a-obsolete (axe-core). A profile with the tags above does not call them. For today’s reference that is defensible: the current edition of WCAG 2.1 dated 6 May 2025 states that the criterion should be considered satisfied for any content using HTML or XML (W3C). Duplicate IDs that break labels or ARIA references are still caught by axe-core through a rule under 4.1.2.

How far automated testing reaches at all is shown by WebAIM’s annual analysis. In the 2026 edition, 95.9 percent of the home pages of the top one million websites had automatically detected WCAG 2 failures (WebAIM Million 2026). At the same time, the authors stress that no automated tool finds all conformance failures and that the absence of detected errors does not prove accessibility (WebAIM Million 2026). For the test profile, this means the automated part is the net that catches common errors early. The manual checklist is not an appendix but the second load-bearing part.

Building the test profile in three layers

A test profile is more than a list of rules. It defines what runs automatically, what a person checks, on which pages, at what intervals and how both are documented. For the transition period, a three-layer structure that serves both editions of the standard has proven practical.

Selecting pages and processes

WCAG does not recognize conformance for parts of a page. It applies to full pages, and when a page is part of a process, all pages in that process must meet the level (W3C). EN 301 549 V4.1.1 explicitly includes the five conformance requirements of WCAG 2.2 in clause 9.6 (ETSI). For the profile, this means selecting by templates and processes, not by individual URLs:

• home page, overview or category page, detail page and a plain content page as representatives of the templates
• login including “forgot password”, because 3.3.8 applies there
• contact and inquiry forms as well as the checkout as complete processes, because 3.3.7 applies there
• pages with sticky bars, cookie notice or chat window for 2.4.11
• pages with sliders, maps or sortable lists for 2.5.7

The manual checklist

• 2.4.11: Tab through the page and check whether the focused component disappears entirely behind sticky bars or overlays. How to approach this systematically is shown in the article on testing keyboard navigation.
• 2.5.7: Trigger every function that requires dragging with a single click or tap. If no such path exists, the finding stays open.
• 3.2.6: Record on all templates where contact details, contact form, help page or chat appear, and check whether they occur in the same order relative to the other content.
• 3.3.7: In every process, note which information is requested a second time and check whether it is auto-populated or available to select.
• 3.3.8: Walk through the login without a memory task: pasting the password allowed, password managers not blocked, an alternative to puzzle CAPTCHAs available.
• 9.7 user preferences: Open the page with forced colors and enlarged text in the browser and check whether settings are overridden, for example via forced-color-adjust.
• Remainder from the automated run: Work through everything axe-core flags as needing manual review and record the result.

User preferences are also one reason why a page looks different on a customer’s device than in your own test. How to track down such deviations is described in the article The site works for us, not for the customer.

Documenting evidence until the citation

During the transition period, wording matters. The statement “conforms to EN 301 549” is ambiguous without an edition, and the statement “conforms to WCAG 2.2” is too broad without a test scope. WCAG itself prescribes required components for a conformance claim: the date, the title, version and URI of the guidelines, the conformance level satisfied, a concise description of the pages the claim covers, and a list of the web content technologies relied upon (W3C). For a test report in the transition period, it pays to add the edition of the standard and the test method to that list.

• Reference: “Tested against WCAG 2.2 Level AA. Until V4.1.1 is cited, the legal reference for demonstrating compliance is EN 301 549 V3.2.1 based on WCAG 2.1 Level AA.”
• Tool: test engine with version number and tags, for example axe-core 4.12 with wcag2a to wcag22aa.
• Scope: list of the templates and complete processes tested, each with a date.
• Separate results: findings on WCAG 2.1 AA and findings on the six new criteria only, in separate sections.
• Manual review: criterion, page, reviewer, date, result and, for defects, the planned date of remediation.
• Exceptions: anything deliberately not met, with reasons, so it can appear in the accessibility statement.

Reporting both levels separately has a practical reason. If a market surveillance authority makes inquiries, today’s reference is what counts. How evidence should be structured in such proceedings is described in the article accessibility enforcement: proving remediation to the authority. The findings on the new criteria belong in the same report, but labeled as a work list for the switch.

What XICTRAQ® checks on the accessibility statement itself is separate from the WCAG scan: whether a statement is linked and whether it contains building blocks of the EU model statement. The documentation on compliance checks describes both checks, their notices and the alert for a low score.

Monitoring regressions instead of testing once

A test profile is only a snapshot if it runs once. Barriers usually arise with changes: a new cookie notice hides the focus, a new login module requires a puzzle, a redesign moves the help link. For the automated part, this means measuring regularly and reporting deterioration. How regressions arise after a deploy and how they get noticed is covered in the article on continuous accessibility monitoring.

In XICTRAQ® monitoring, the accessibility scan runs daily on the Free plan and every 12 hours on all other plans, as the pricing overview shows (XICTRAQ). Each run delivers a score from 0 to 100 and breaks down violations, items requiring manual review and passed rules. If the score drops below 50, monitoring raises an alert, below 30 with critical severity (XICTRAQ). It is delivered through the configured notification channels.

For the five manual criteria, measurement helps indirectly. The screenshot changelog shows when a page has changed visibly, for example through a new sticky bar or a redesigned form. A fixed team rule has proven useful: every change to header, footer, login or checkout triggers a manual re-check of the related criteria.

Roadmap until the citation

1. Now: switch the test profile to the tags up to wcag22aa, create the manual checklist for the other five criteria and clause 9.7, and save the first run as a baseline.
2. In the coming weeks: fix findings on WCAG 2.1 AA first, because they concern today’s reference. Move findings on the new criteria to a separate list with dates.
3. Ongoing: keep the automated part running in monitoring and re-check the manual items with every change to templates and processes.
4. At the citation: switch the test report and accessibility statement to EN 301 549 V4.1.1 and update references to WCAG 2.1 AA in texts, contracts and service descriptions.

Statements in your own texts that name WCAG 2.1 AA as the benchmark remain correct until the citation, but they belong on the list now. For agencies that look after many client sites, the switch is also an occasion for an offer: a test against WCAG 2.2 with separate reporting works well as an entry point, much like a website check as a lead magnet.

Run the test profile on two levels now

EN 301 549 V4.1.1 changes the benchmark, but not yet the legal situation. Until the citation, V3.2.1 with WCAG 2.1 AA remains the reference; afterwards the new edition confers the presumption of conformity (AccessibleEU). Anyone who sets the test profile to WCAG 2.2 today and reports both levels separately loses nothing in today’s evidence and mainly has to change the weighting in the report at the switch. Of all this, only target size can be tested automatically; the checklist carries the rest.

The automated part is handled by the XICTRAQ® accessibility check with regular runs, a score history and an alert once the score drops below 50. The live demo shows what this looks like in the dashboard, and your own test starts with free registration.