EN 301 549 V4.1.1: what changes and what WCAG 2.2 adds

EN 301 549 V4.1.1 is the revision of the European accessibility standard for ICT that ETSI published in September 2026. For web pages it changes four things: clause 9 now follows WCAG 2.2 Level A and AA instead of WCAG 2.1, the Parsing requirement is gone, six new success criteria and a new clause on user preferences are added, and live subtitles join the web-page table, Table A.1. It does not yet carry legal weight: until its reference is published in the Official Journal of the EU, conforming to it gives no presumption of conformity.

This post is the change list. For the law the standard serves, start with what the European Accessibility Act asks of a website.

What V4.1.1 is, and what it replaces

EN 301 549 is the European standard of accessibility requirements for ICT: websites, documents, software, hardware and the support around them. Its clause 9 holds the requirements for web pages, and those requirements are, apart from 9.6 and 9.7, WCAG success criteria, renumbered: WCAG 1.4.3 becomes EN 301 549 9.1.4.3.

The version cited in the Official Journal today, V3.2.1 from March 2021, adopts WCAG 2.1. It is the harmonised standard under the Web Accessibility Directive, which covers public-sector websites; Implementing Decision (EU) 2021/1339 cites it.

V4.1.1 was written to serve both Directives. Its Annex F says the whole document “has been revised to become a harmonised standard for Directive (EU) 2019/882 … and for Directive (EU) 2016/2102”, the European Accessibility Act and the Web Accessibility Directive. So the version change matters to private and public sites alike.

The annexes that say which clauses apply were restructured too. Table A.1 in Annex A is now the European Accessibility Act’s table for “Where the ICT is, or includes, a web page”, and the Web Accessibility Directive’s mapping moved to a new Annex ZA. Here we stay with what changed.

The web-page rows that changed

V3.2.1’s Table A.1 lists 50 clause-9 rows for web content. V4.1.1’s Table A.1 lists 57, each with the condition “Where ICT is, or includes, a web page”: the 55 WCAG 2.2 Level A and AA criteria, plus 9.6 (conformance) and 9.7 (user preferences). One row left, eight arrived.

9.4.1.1 Parsing is gone

WCAG 2.2 removed success criterion 4.1.1 Parsing. W3C’s note explains that assistive technology “no longer has any need to directly parse HTML”, so the problems the criterion addressed “either no longer exist or are addressed by other criteria”. V4.1.1 follows, so a duplicate id or an unclosed element is no longer a failure in itself under the new version. It can still cause one: if two elements share the id that an aria-labelledby points at, the control can end up with the wrong name, and that is a 4.1.2 Name, Role, Value problem.

Until V4.1.1 is cited, keep Parsing on your list where V3.2.1 applies. W3C’s own introduction to WCAG 2.2 says that authors required by policy to conform to WCAG 2.0 or 2.1 “may need to continue to test and report 4.1.1”.

Six WCAG 2.2 criteria join the table

WCAG 2.2 added nine success criteria. Three are Level AAA and stay outside the table; the six at Level A and AA are now EN 301 549 requirements for web pages. Each one gets a short reading here. For the detail, see the nine criteria WCAG 2.2 added.

9.2.4.11 Focus not obscured (minimum), WCAG 2.4.11. When a control receives keyboard focus, it must not be entirely hidden by content the author created, the usual culprits being sticky headers, cookie banners and chat launchers. A control that is only partly covered passes this criterion; the Level AAA criterion 2.4.12 is the one that asks for no overlap at all. Can automated tools detect this? Partly. A browser-based check can focus each control and test whether fixed or sticky content covers it completely. Content the user opened and can dismiss, states such as a banner that appears mid-session, and other screen widths require manual review.

9.2.5.7 Dragging movements, WCAG 2.5.7. Anything done by dragging, such as a slider, a sortable list or a map pan, must also work with a single pointer without dragging, unless dragging is essential or the dragging is the browser’s own, such as scrolling, and not changed by the author. Can automated tools detect this? Not reliably. Finding drag handlers is possible; deciding whether an alternative exists requires manual review.

9.2.5.8 Target size (minimum), WCAG 2.5.8. Pointer targets are at least 24 by 24 CSS pixels. A smaller target passes when a circle 24 CSS pixels across, centred on it, does not intersect another target or another small target’s circle, or when another control on the page that meets the criterion does the same job. Targets in a sentence or held to the line height of the surrounding text, controls whose size the browser sets and the author has not changed, and sizes that are essential or legally required are exempt. Can automated tools detect this? The measurement, yes. The exceptions require manual review.

9.3.2.6 Consistent help, WCAG 3.2.6. If help (contact details, a contact form, a chat, a self-help page) is repeated across a set of pages, it appears in the same order relative to the other content on each page, unless the user initiates a change, such as zooming. Can automated tools detect this? Only by comparing pages, and deciding what counts as a help mechanism requires manual review.

9.3.3.7 Redundant entry, WCAG 3.3.7. Information a person already entered, or was given, in the same process is filled in for them or offered for selection. The exceptions: re-entering it is essential (a memory game, for example), it is needed for security (confirming a new password, for example), or the earlier value is no longer valid. Can automated tools detect this? No. It depends on the steps of a process and what each one asks for, which requires manual review.

9.3.3.8 Accessible authentication (minimum), WCAG 3.3.8. No step of signing in may depend on a cognitive function test, such as remembering a password or solving a puzzle, unless there is an alternative, a mechanism that helps (paste and password managers count), or the test is recognising objects or picking out an image, video or sound the user gave the site earlier. Asking only for an email address and sending a one-time code can meet it, because an email address is not a test; retyping the code is. The code step passes when the code can be pasted and the field does not stop the browser filling it in; one field marked autocomplete="one-time-code" usually does both. Separate one-digit boxes that refuse a pasted code fail. An emailed sign-in link avoids the code altogether. Can automated tools detect this? Some of it. A check can find credential fields that block paste or switch off autofill. Whether a puzzle or a sign-in flow has an acceptable alternative requires manual review.

Our own audit rules test three of the six: a focused control covered by other content at its centre and corners (2.4.11), touch targets under 24 pixels without enough spacing (2.5.8), and sign-in fields that refuse paste or autofill (3.3.8). We have no automated check for 2.5.7, 3.2.6 or 3.3.7.

Live subtitles, and “captions” becomes “subtitles”

V3.2.1 already had clause 9.1.2.4 for live captions, but it was not in the web table the Web Accessibility Directive used, because that Directive does not apply to live time-based media. The European Accessibility Act has no such exclusion, so V4.1.1’s Table A.1 includes 9.1.2.4: if an in-scope site streams live video with sound, the stream needs live subtitles. The Web Accessibility Directive’s table, now Table ZA.1, still leaves it out.

The 9.1.2.x titles now say “subtitles” where V3.2.1 said “captions”. The WCAG criteria behind them did not change.

Clause 9.7: leave the user’s settings alone

Clause 9.7 is new to clause 9, and it is EN 301 549’s own requirement rather than a WCAG criterion. For public-sector sites the idea is not new: V3.2.1 already listed clause 11.7 User preferences in its web-content table, and Table ZA.1 has 9.7 in its place. It says that a web page “shall not block the user agent’s mode(s) of operation that present the web page according to user preference settings, or explicitly override user preference settings for documented platform accessibility features in these modes of operation, unless this is essential to the information or function of the web page.”

In practice: people set up their browser or operating system to show content the way they can use it, and a page should let those settings work. The standard’s notes list the kind of features meant, “colour filters, contrast, text size, pointer size, and text cursor”, and give one concrete example of an explicit override: the CSS property forced-color-adjust.

Set to none, that property opts an element, and what it contains, out of forced colours: the mode in which the browser replaces a page’s colours with a palette the user chose, such as a Windows contrast theme. Setting it to none across a whole site is the kind of override 9.7 limits to essential cases.

/* Every element keeps the site's colours, whatever the user chose. */* {  forced-color-adjust: none;}

/* A colour swatch shows the colour itself, so overriding is essential here. */.swatch {  forced-color-adjust: none;}​/* Everywhere else, work with forced colours instead of against them. */@media (forced-colors: active) {  .button {    border: 1px solid ButtonText;  }​  :focus-visible {    outline: 2px solid Highlight;  }}

The first version overrides the user’s colours on every element. The second leaves the mode alone and uses system colour keywords (ButtonText, Highlight) so borders and focus outlines stay visible in the user’s palette. The one exception, a swatch whose colour is the information, is the kind of case the clause calls essential.

Can automated tools detect this? Finding forced-color-adjust: none in a stylesheet is easy. Deciding whether it is essential where it is used requires manual review, as does checking the other preference features the notes name.

What “cited” means, and what it does not

A harmonised standard matters because of one article. Article 15(1) of the European Accessibility Act says that products and services conforming to “harmonised standards or parts thereof the references of which have been published in the Official Journal of the European Union, shall be presumed to be in conformity with the accessibility requirements of this Directive in so far as those standards or parts thereof cover those requirements”. V4.1.1 repeats the condition in its own clause A.2.0: the presumption applies “once the present document is cited in the Official Journal”.

Three things follow.

• Until the citation, V4.1.1 gives no presumption under either Directive. AccessibleEU, the Commission’s accessibility resource centre, puts it plainly: the new version “is not yet the legal reference standard for demonstrating compliance” with the European Accessibility Act or the Web Accessibility Directive.
• The Act’s requirements apply anyway. Your duty comes from the Act’s Annex I, through national law. A cited standard is a voluntary way to show you meet it, and conforming to it gives a presumption of conformity; it is not the source of the duty. That is why we suggest testing against WCAG 2.2 now (see below).
• The presumption lasts only while the reference stays listed. Clause A.2.0 adds that it “stays valid only as long as a reference to the present document is maintained in the list published in the Official Journal”.

If you are still working out whether the Act covers your business at all, settle that first; the micro-enterprise exemption and the list of covered services decide more than the version of the standard does.

The dates around V4.1.1

V4.1.1 lists four dates in its table of national transposition dates, and ETSI’s publication date makes five. They are often misread: none of them is an Official Journal citation date, and the doa, dop/e and dow are milestones for national standards bodies, which must implement every EN as a national standard, by publishing it or endorsing it. The only citation date anyone has set is ETSI’s own target, shown in the table below.

Several pages give 30 November 2026 as the expected citation date. In the standard it is the doa, a national-standards milestone. ETSI’s own work programme lists citation in the Official Journal as the next step, with a target of 16 December 2026, after the standard was delivered to the Commission on 23 September 2026. That is ETSI’s planning date, not a commitment: the Commission decides when the reference is published.

What to do before the citation

• Test against WCAG 2.2 Level AA now, plus Parsing while V3.2.1 applies. WCAG 2.2 contains every 2.1 criterion except Parsing, so 2.2 Level AA with 4.1.1 added covers the WCAG requirements of both versions. Clause 9.7, and the standard’s other applicable rows, come on top. Building to the older version alone means testing again once V4.1.1 is cited.
• Start with the six additions and 9.7. They are the requirements that are new for web pages. Everything else in clause 9 was already there, though for a site under the Act, 9.1.2.4 live subtitles is new to the table.
• Check your stylesheets for forced-color-adjust: none. It is the clause-9.7 problem easiest to find with a text search, though each hit still needs a check of whether it is essential.
• Date and version your test records. Write down which standard and version you tested against, how, when, and which pages stood for which templates. When the citation lands, the records show what still holds.
• If you also sell outside the EU, compare the EAA with the US and Ontario rules before you plan your testing, because they are built differently.

When our audits report a finding from a WCAG-mapped rule, it carries the WCAG criterion and the matching EN 301 549 clause, and a criterion that V3.2.1 does not include is marked “Beyond EN V3.2.1”. So you can see at a glance which findings belong to the WCAG 2.2 additions.

Scan a page of your site, free and without signing up, to see the findings for one page.