EN 301 549 v4.1.1 is here · What it changes and what to do now

The short version

On September 2, 2026, ETSI published EN 301 549 v4.1.1, the new version of Europe's technical accessibility standard for websites, apps, PDFs, software and telecom products. For the next lined, I'll call it "the standard", easier for screen readers. It's a big deal, but it's not a deadline yet. Think of it as the final draft becoming the official rulebook, while the referee (the European Commission) hasn't blown the whistle to start the match.

If you're responsible for a website, an app, or accessibility compliance at your organization, in Luxembourg, France, or anywhere in the EU, here's what actually changes, when it starts to matter legally, and what to do about it starting today.

Why this update exists

This norm is the technical standard behind the European Accessibility Act (EAA). The EAA is the directive that says "your digital products and services must be accessible." The standard EN 301 549 is the detailed rulebook that says exactly what "accessible" means in practice, mostly by pointing to WCAG success criteria plus extra requirements the EAA needs (real-time communication, hardware, self-service terminals, and so on), that are for most of them already integrated into RAWeb 1.1, the referential for Luxembourg.

Until now, that rulebook was built on WCAG 2.1. The new v4.1.1 version of the standard rebuilds it on WCAG 2.2, plus a substantial rewrite of the rules for real-time communication (think video calls, chat, captions during calls).

Three steps, not one deadline

This is the part that trips people up, including plenty of professionals. Publication doesn't equal legal obligation. There are three separate milestones, and confusing them is the single most common mistake right now.

1. Publication by ETSI, done. The standard in v4.1.1 was formally published on September 2, 2026. The technical content is final and won't change again.
2. Citation in the Official Journal of the EU (OJEU), pending. This is the step that actually matters legally. Until the European Commission cites v4.1.1 in the OJEU, it doesn't carry "presumption of conformity," the legal safe harbor that says "if you followed this standard, you're presumed to comply with the law." Right now, the current v3.2.1 (built on WCAG 2.1) is still the legally recognized version. Citation is expected around November 30, 2026, though several trackers note this date isn't confirmed by the Commission and could shift.
3. Transposition into each country's national law. The EAA is a directive, not a regulation, so each EU country writes its own implementing law. Some of those laws point to EN 301 549 without specifying a version number. If yours is one of them, the new version could become your legal benchmark automatically, with zero new legislation needed on your side. In Luxembourg, the reference framework for websites is RAWeb, already aligned with this standard, and expected to evolve alongside it.

Why start now anyway? Because whichever version ends up being cited, WCAG 2.2 is where things are heading, and building or fixing things now against 2.1 won't invalidate your work, but it'll make in incomplete. If your national law doesn't pin a version number, the new requirements could apply to you before you expect.

What actually changes, in plain terms

The headline change for websites, apps, and documents is the jump from WCAG 2.1 to WCAG 2.2, which adds six new success criteria. We've talked about those new WCAG 2.2 criteria in a previous article. Here's what each one means for a real user, not just for an auditor's checklist.

• Focus Not Obscured (AA): when you tab through a page with your keyboard, the thing you've selected must actually be visible, not hidden behind a sticky header or a cookie banner.
• Dragging Movements (AA): anything you'd normally drag (like a slider or reordering a list) needs a way to do it without dragging, for people who can't perform that motion precisely.
• Target Size Minimum (AA): clickable buttons and icons need to be at least 24 by 24 pixels, so people with limited motor precision or larger fingers on touchscreens can actually hit them.
• Consistent Help (A): if a help link, chat button, or contact option appears on multiple pages, it needs to stay in the same relative place each time, so people don't have to hunt for it.
• Redundant Entry (A): if a user already gave you a piece of information (like their address on a previous step), don't make them retype it. Auto-fill it or let them select it again.
• Accessible Authentication Minimum (AA): login steps that rely on solving a puzzle or remembering something (a classic CAPTCHA, for instance) need an accessible alternative that doesn't rely on that specific cognitive task.

Two things worth knowing here: First, some of these criteria (target size, dragging, focus visibility) live largely in your design system, in your buttons, sliders, and layout components, which is exactly why fixing them at the component level, rather than page by page, is the efficient path. Second, meeting WCAG 2.2 AA is necessary but not sufficient for the European standard conformance. The standard also covers things WCAG doesn't touch, like the reworked real-time communication requirements for calling, messaging, and video-conferencing products, where the scope of "real-time text" support has expanded significantly. If your organization builds that kind of product, budget for a meaningfully bigger effort there specifically.

What to actually do this week

You don't need a six-month task force to get started. A few concrete moves:

• Audit against WCAG 2.2 now, not 2.1, even if your national law technically still points to the older version. CheckFox's WCAG standard already includes the full 2.2 criteria set, so you're testing against tomorrow's requirement today, not yesterday's.
• Check what your national law actually references. If it names EN 301 549 without a version number, you may already be on the hook for v4.1.1 whenever it's cited. If you're in Luxembourg, the RAWeb framework is the one to watch.
• Expect new findings on things that used to pass. That's not a regression in your product, it's a raised bar. Plan for it instead of being surprised by it.
• Start at the design system, not the page level. Target size, drag alternatives, and focus visibility are almost always more efficient to fix once in a shared button, slider, or modal component than scattered across every page that uses them.
• If you build real-time communication tools (calling, chat, video), start scoping the Clause 6 changes early. This is the part most likely to require an actual technical refactor rather than a design tweak.
• Focus on your services, not just a website. That's why I'm proposing Accessibility Journeys with CheckFox.

How CheckFox and I can help with this transition

I'm Geoffrey, the person building CheckFox and also a working accessibility auditor. I built this accessibility toolset specifically because I was tired of maintaining spreadsheets and static checklists every time a standard evolved, exactly what's happening right now with EN 301 549 v4.1.1.

Two ways I can help you navigate this update, depending on what you need.

If you want to audit it yourself: CheckFox already has WCAG 2.2 built in, along with RGAA, RAWeb, RAAM, and RAPDF, all mapped to EN 301 549. You don't need to build your own checklist or wait for someone to update a PDF. Map your full user journey across your website, app, PDFs and emails, run audits against the current criteria, and generate an audit-ready accessibility statement in a couple of clicks.

When guidelines evolve again (and they will), CheckFox's versioning lets you carry forward what you already tested and show real progress over time, instead of starting from zero.

If you'd rather have someone else run the audit: I offer accessibility audit services directly, covering the same standards CheckFox is built on: WCAG, RGAA, RAWeb, RAAM, and RAPDF. If you're not sure whether the EAA even applies to your organization yet, start with the free self-assessment on the EAA page, it takes about a minute and points you toward what to look at first. From there, I can help you scope a transition plan toward conformance (and more) that fits your release calendar, rather than treating this as a fire drill in November.

Either way, the point isn't to panic about a citation date that might move. It's to stop testing against a standard that's already on its way out, and start building toward the one that's coming. Start a free CheckFox audit today, or reach out directly if you'd like a hand scoping what this update means for your specific product.

Sources & Resources

• EN 301 549 V4.1.1 Is Now Published: What It Means for Digital Commerce
• The European accessibility standard EN 301 549 has been updated