EN 301 549 v4.1.1: What Changed for EU Client Sites

If you audit sites for clients in the EU, the ground moved this month. ETSI, CEN and CENELEC published EN 301 549 V4.1.1 (2026-09), the first revision of the European accessibility standard since V3.2.1 in March 2021. The headline for web work is short: the web requirements now point at WCAG 2.2 instead of WCAG 2.1.

That means every site you signed off against WCAG 2.1 AA now has seven open items: six WCAG 2.2 success criteria, plus a new clause 9.7 on user preferences that no version of WCAG covers. This post covers what changed, which criteria they are, what clause 9.7 asks for, where each EU law stands on citing the new version, and what to re-test on a site you already audited.

What v4.1.1 changes

The standard's own foreword lists the significant changes since V3.2.1:

• The Real-Time Text requirements in clause 6.2 were significantly revised and extended to include total conversation.
• Clauses 9 (web), 10 (non-web documents) and 11 (non-web software) were all updated to align with the WCAG 2.2 Recommendation.
• A new Annex ZA maps the standard to Directive (EU) 2016/2102, the Web Accessibility Directive for public sector bodies.
• A new Annex ZB maps it to Directive (EU) 2019/882, the European Accessibility Act.
• A new clause A.2 lets a specific ICT product or service be evaluated against the EAA's essential requirements.

For an agency building and auditing websites, the second and fourth points are the ones that land on your desk. The standard is also explicit about the equivalence, in clause 9.0:

Conformance with W3C Web Content Accessibility Guidelines (WCAG 2.1) Level AA is equivalent to conforming with all of clauses 9.1 to 9.4 except 9.2.4.11, 9.2.5.7, 9.2.5.8, 9.3.2.6, 9.3.3.7, 9.3.3.8 and with the conformance requirements of clause 9.6 of the present document.

In other words, the standard itself names your gap. Those six clause numbers are most of the work. Read the next bullet in the same clause too: conformance with WCAG 2.2 Level AA is equivalent to conforming with all of clauses 9.1 to 9.4 and with the conformance requirements of clause 9.6. That list stops there, so the new clause 9.7 sits outside the equivalence and needs a check of its own, even on a site built to WCAG 2.2 AA.

The six criteria that are new since WCAG 2.1

WCAG 2.2 added nine success criteria, but three of them are AAA. The six at Level A and AA are the ones EN 301 549 V4.1.1 now requires. Full list and levels are in the W3C's new features in WCAG 2.2.

2.4.11 Focus Not Obscured (Minimum)

When a component receives keyboard focus, it must not be entirely hidden by author-created content (W3C Understanding 2.4.11). On a modern marketing site the offender is almost always a sticky header, a cookie bar or a chat widget sitting over the element the browser just scrolled to.

/* Broken: the sticky header covers whatever focus scrolls into view */
.site-header { position: sticky; top: 0; height: 72px; }

/* Fixed: reserve the header height on the scroll container */
.site-header { position: sticky; top: 0; height: 72px; }
html { scroll-padding-top: 72px; }

Automated tools rarely catch this one, so put it on the manual pass. Our keyboard and focus checker covers the related focus failures, and the detail is in our guide to keyboard navigation.

2.5.7 Dragging Movements

Anything operated by dragging needs a single-pointer alternative, unless the dragging is essential or comes from the user agent (W3C Understanding 2.5.7). Think drag-to-reorder lists, map panning, range sliders and carousels that only respond to a swipe. The fix is usually a pair of buttons, not a rebuild.

2.5.8 Target Size (Minimum)

Pointer targets must be at least 24 by 24 CSS pixels, with exceptions for spacing, inline links in text, user agent defaults, an equivalent control elsewhere on the page, and essential presentation. The spacing exception is measured: a 24 CSS pixel diameter circle centred on each undersized target must not intersect another target or another such circle (W3C Understanding 2.5.8).

/* Broken: a 16px hit area, so the row of icons fails */
.social { display: inline-flex; }
.social svg { width: 16px; height: 16px; }

/* Fixed: padding takes the hit area to 24px, the icon still reads as 16px */
.social { display: inline-flex; padding: 4px; }
.social svg { width: 16px; height: 16px; }

The patterns that fail most are icon-only social rows, table row actions, pagination, close buttons and dense footer link lists. Check yours with the target size checker.

3.2.6 Consistent Help

If a page carries a help mechanism (human contact details, a human contact mechanism, a self-help option, or a fully automated contact mechanism) and it repeats across a set of pages, it has to appear in the same order relative to other page content (W3C Understanding 3.2.6). Templates that move the support link from the header on marketing pages into the footer on checkout pages fail this.

3.3.7 Redundant Entry

Information the user already entered in the same process must be auto-populated or available to select, unless re-entry is essential, required for security, or the earlier value is no longer valid (W3C Understanding 3.3.7). The classic failure is a form that clears every field after a validation error.

3.3.8 Accessible Authentication (Minimum)

A cognitive function test cannot be the only way through a step of authentication (W3C Understanding 3.3.8). W3C is direct about the common cause: if password managers are blocked from filling fields, or users cannot paste, the page fails unless an alternative exists.

<!-- Broken: paste blocked, password managers shut out -->
<input type="password" name="pw" autocomplete="off" onpaste="return false">

<!-- Fixed: let the password manager and the clipboard do the work -->
<input type="password" name="pw" autocomplete="current-password">

Puzzle CAPTCHAs on a login also fail unless you offer an alternative that is not a cognitive test. More on input patterns in our guide to accessible forms.

New clause 9.7: user preferences for web pages

Clause 9 in V3.2.1 ended at 9.6. V4.1.1 adds clause 9.7 "User preferences for web pages", and it is the one new web requirement with no WCAG success criterion behind it. The requirement itself (ETSI PDF page 70) reads:

Where ICT is, or includes, a web page, the 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.

The notes under it make that concrete. Note 3 says that for web pages the underlying platform is the user agent. Note 4 says the clause "does not preclude the web page from specifying other values, but it does limit the use of specifications that explicitly override user settings (e.g. 'forced-color-adjust' property in CSS) to cases where this is essential". Note 5 lists features that might be documented as platform accessibility features: colour filters, contrast, text size, pointer size and text cursor.

For most agency work that lands on one thing: forced colors. When someone turns on a Windows contrast theme, the browser replaces your palette with their chosen colours, and the CSS forced-color-adjust: none declaration opts an element out of that. Using it on a whole component because the brand colours looked wrong is exactly the override the clause limits.

/* Broken: the card opts itself and every child out of the user's contrast theme */
.pricing-card { forced-color-adjust: none; background: #101828; color: #f2f4f7; }

/* Fixed: let forced colors apply, and adapt inside the media query instead */
.pricing-card { background: #101828; color: #f2f4f7; }

@media (forced-colors: active) {
  .pricing-card { border: 1px solid CanvasText; }
}

The exception is real but narrow: where the colour is the information, as in a colour swatch or a chart key, keeping it can be essential. Then scope the opt-out to that element only, and give the same information a second cue that is not colour. The forced-colors media query is how you adjust the rest.

How to test clause 9.7

Annex C sets the test (C.9.7) as an inspection with three checks: that the page does not block the user agent modes that present it according to user preference settings, that it does not explicitly override user preferences for documented platform accessibility features in those modes, and, for each preference that is overridden, whether meeting it would fundamentally alter the information or function of the page.

• Turn on a contrast theme in Windows settings and walk each template, watching for text, icons and focus outlines that keep their original colours or disappear.
• Or emulate it: in Chrome DevTools open the Rendering panel and set Emulate CSS media feature forced-colors to active.
• Search the stylesheets for forced-color-adjust and write down, per hit, why it is essential. Anything you cannot justify comes out.
• Check the same templates at the operating system's larger text and pointer settings, since the clause covers those preferences too.

One requirement went away

Clause 9.4.1.1 is now Void. The standard notes that earlier versions referenced 4.1.1 Parsing from WCAG 2.0 and 2.1, and that WCAG 2.2 removed it because the problems it was meant to prevent "either no longer exist or are addressed by other criteria". If your report template still lists duplicate IDs and unclosed tags as a WCAG failure, retire that row. The markup is still worth fixing, it is just no longer this criterion.

Which law cites which version

Publication by ETSI and citation in the Official Journal of the European Union are two different events, and only the second one carries legal weight. V4.1.1 says so itself, in the foreword:

Once the present document is cited in the Official Journal of the European Union under that Directive, compliance with the normative clauses of the present document given in the tables in clause A.2 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding essential requirements of that Directive and associated EFTA regulations.

"That Directive" there is the European Accessibility Act: V4.1.1 was prepared under the Commission's standardisation request C(2022) 6456 final for Directive (EU) 2019/882, and clause A.2 and Annex ZB are the parts that map to it. Annex ZA carries the same sentence for the Web Accessibility Directive and its own tables. Two laws, two citation states, and the difference matters for what you can tell a client.

Under the Web Accessibility Directive, V3.2.1 is the cited version. Commission Implementing Decision (EU) 2021/1339 put "EN 301 549 V3.2.1 (2021-03)" on the list of harmonised standards for Directive (EU) 2016/2102 in August 2021, and that entry is still what public sector bodies rely on. Annex ZA warns that the presumption "stays valid only as long as a reference to the present document is maintained in the list published in the Official Journal of the European Union", and tells users to consult that list frequently. When V4.1.1 is cited there, WCAG 2.2 AA becomes the public sector baseline.

Under the EAA, there is nothing to replace. No version of EN 301 549 appears on the Commission's list of harmonised standards for Directive (EU) 2019/882: the one accessibility entry there is the public sector websites and mobile applications one, under the other directive. V4.1.1 is also the first version written for the EAA at all. Its foreword records that V3.2.1 was prepared under standardisation request C(2017)2585 final for Directive (EU) 2016/2102, and V3.2.1 does not mention Directive (EU) 2019/882 anywhere: its Annex A, which V4.1.1 renamed Annex ZA, covers the Web Accessibility Directive only.

V4.1.1 does not fix a citation date either, under either law. Its transposition table gives the national timetable only: adopted 24 August 2026, latest announcement 30 November 2026, national publication or endorsement by 31 May 2027, and withdrawal of conflicting national standards by 31 May 2028. None of those dates is an Official Journal citation.

So what do you tell a client? Not "you are now non-compliant", and not "the cited standard still lets us stop at WCAG 2.1". The honest version is: the standard that will be cited requires WCAG 2.2 AA, the six extra criteria and the new user preferences clause are small and cheap compared with a second audit cycle, and building to WCAG 2.2 now means the citation is a non-event for them.

What to re-test on a site you already audited

You do not need to redo the audit. You need a delta pass on the six criteria and clause 9.7, run per template rather than per page, plus a check that nothing in your report overclaims. Budget roughly 30 to 45 minutes per template.

1. Tab through every template with the sticky header, cookie bar and chat widget live, and watch for focus disappearing behind them (2.4.11).
2. List every drag interaction: sliders, carousels, maps, sortable tables, file upload zones. Each needs a click-only route (2.5.7).
3. Measure the small targets: social icons, pagination, table row actions, close buttons, footer links (2.5.8).
4. Compare where the help or contact mechanism sits across marketing, account and checkout templates (3.2.6).
5. Submit each multi-step form with a deliberate error and check what survives (3.3.7).
6. Try to paste into the password and one-time-code fields, and check whether a password manager can fill them (3.3.8).
7. Turn forced colors on and walk each template, then grep the CSS for forced-color-adjust and justify every hit (9.7).
8. Remove 4.1.1 Parsing from the report template and re-map findings to 1.3.1 or 4.1.2 where they still apply.

A scan will get you through steps 2, 3, 5 and 6 quickly across a lot of pages. Start with a free accessibility scan of a representative page, then do the manual pass. Automated checks find many problems but cannot confirm conformance with the standard, so say that plainly in the report. Our breakdown of the nine WCAG 2.2 criteria has the detail on what tooling can and cannot see, and the audit checklist covers the rest of the pass.

What to tell a client under the EAA

The European Accessibility Act has applied to products and services placed on the market since 28 June 2025, and it covers e-commerce, consumer banking, e-books, telephony, transport services and more (European Commission). What it requires sits in the directive itself, in the essential requirements in Annex I. A harmonised standard is a voluntary route to showing you meet them, not the only one, and it gives a presumption of conformity rather than a certificate.

The part worth being careful about: because no version of EN 301 549 is cited under the EAA yet, none of them gives an EAA client that presumption today. If a client or a supplier's sales deck tells you "V3.2.1 is the cited version, so WCAG 2.1 AA is enough", that citation is under the Web Accessibility Directive, which covers public sector bodies and not them.

What you can offer instead is evidence. V4.1.1 is the only version that maps its clauses to the EAA's essential requirements, in Annex ZB and in clause A.2 for assessing one specific product or service, and on the web side that means WCAG 2.2 AA. Building to it now is the strongest position you can document for a client, and it makes the citation a non-event whenever it lands.

Three things worth saying to a client, in their words:

• The law already applies to you. What is missing is the official shortcut for proving you meet it, not the obligation itself.
• We build to the newest version of the standard, which uses WCAG 2.2 AA, so the seven extra checks are covered. When the EU cites that version, nothing changes for you.
• Nobody can certify you compliant. We can show which requirements your site meets, which it does not, and what it would take to close the gap.

Your next steps

• Re-baseline your audit template on WCAG 2.2 AA and add the six clauses and clause 9.7 with their EN numbers beside them.
• Run the eight-step delta pass above on every client site you signed off against WCAG 2.1.
• Fix 2.4.11 and 2.5.8 first. They are CSS-level changes on most sites and they affect every page.
• Update any accessibility statement that names EN 301 549 V3.2.1 or WCAG 2.1 AA, and keep it honest about open failures.
• Watch the Official Journal list for the citation rather than guessing at a date, and put a line in your retainer scope about re-testing when it lands.