EN 301 549 V4.1.1: what changed, and which version still counts
The standard behind the European Accessibility Act has a new version, published in September 2026. It takes WCAG 2.2 into the software clause. The version the law points at, though, is still V3.2.1 from 2021. Here is the difference, requirement by requirement, and what a mobile app audit has to answer for today.
Which version the law points at
A standard becomes the legal reference when its reference is published in the Official Journal of the European Union. That is what gives conformity with it the presumption of conformity with the law. For EN 301 549 the cited version is V3.2.1, from March 2021, which carries WCAG 2.1 level AA.
V4.1.1 was published in September 2026. As of today it is not cited, so it changes no obligation by itself. AccessibleEU, the Commission's own centre, said on 7 September 2026 that until the citation arrives the current reference remains V3.2.1.
National texts are moving to a dynamic reference rather than a fixed version. In France, décret n° 2026-816 of 24 August 2026 rewrote the older decree so that a service is accessible when it conforms to the harmonised standards whose references are published in the Official Journal. When the citation changes, the obligation follows it without another decree.
The practical consequence for anyone auditing today: a report that answers only for V4.1.1 does not answer the question the law asks, and a report that answers only for V3.2.1 ignores WCAG 2.2. Both versions have to be in the table.
What clause 11 gained
Clause 11 is the software part, the one a mobile app answers to. In V4.1.1 it carries the 50 WCAG 2.2 criteria of levels A and AA that apply to software, against WCAG 2.1 in V3.2.1.
Seven requirements in clause 11 have no counterpart in V3.2.1. Five come from WCAG 2.2: 11.2.4.11 Focus not obscured (minimum), 11.2.5.7 Dragging movements, 11.2.5.8 Target size (minimum), 11.3.3.7 Redundant entry and 11.3.3.8 Accessible authentication (minimum). Two were simply void in V3.2.1 and are requirements now: 11.2.4.2, which takes over WCAG 2.4.2 as Non-web software titled, and 11.3.2.4 Consistent identification.
Of those, 11.2.5.8 is the one that changes the result of most mobile audits. A touch target below 24 by 24 was advice under WCAG 2.1 and is a failure under 2.2, and small targets are the defect our own checks find most often.
One WCAG 2.2 criterion did not make it into the software clause: 3.2.6 Consistent help. Clause 11.3.2.6 is void, so an app is not measured against it here.
What it lost, and what only moved
Parsing is gone. WCAG 2.2 removed criterion 4.1.1, and with it went V3.2.1's requirement 11.4.1.1.1. If an old report fails an app on parsing, that finding no longer exists.
Requirements about the accessibility services themselves were rewritten. V3.2.1 asked software to use the platform's documented accessibility services (11.5.2.3) and asked platforms to provide them (11.5.2.1, 11.5.2.2). In V4.1.1, 11.5.2.3 is a recommendation and 11.5.2.2 is void, while the platform duty is stated once in 11.5.2.1.
Authoring tools moved out of clause 11 into clause 5: the five requirements numbered 11.8.1 to 11.8.5 are now 5.10.1 to 5.10.5, with the same titles.
Documentation and support were restructured. V3.2.1's 12.1.1, 12.1.2, 12.2.2, 12.2.3 and 12.2.4 became 12.1, 12.2 and 12.3, with electronic programme guides added as 12.4 and 12.5.
Clause 6, for apps with calls, was rewritten around operational scenarios (6.0.2 to 6.0.9) and its real-time text requirements were renumbered and renamed. Clause 7 now says subtitles where V3.2.1 said captions.
Numbers that survived a renumbering are the trap. In V3.2.1, 6.2.3 is Interoperability; in V4.1.1 the same number is DTMF touch-tone generation during RTT operations. A correspondence table has to match requirements, not numbers.
What an audit has to answer for today
Counting the requirements that a native mobile app can meet or miss, our protocol answers for 144 of them: the V4.1.1 requirements from clauses 5, 6, 7, 11 and 12, plus the 19 requirements of V3.2.1 that have no identical counterpart in V4.1.1 and still belong to the version the law cites.
Every requirement is verified by hand on the screens in the report, with the screen readers of the test environment named in it. Automated checks run alongside and point at the line of code, but they answer for a part of the list, not for it.
The report states the clause in both numberings, so the same document answers a regulator reading V3.2.1 and a team preparing for V4.1.1.
Or have the whole build checked: the store readiness audit is €190, 2 working days.