A practical guide for accessibility, product, legal, and procurement teams responsible for EU-facing websites and mobile apps.
A new standard is here, and the clock has started
On September 2, 2026, ETSI, CEN, and CENELEC officially published EN 301 549 V4.1.1, the harmonised European standard for ICT accessibility. This is the technical standard that underpins the European Accessibility Act (EAA). Most EU member states use this standard to define “accessible” for websites, mobile apps, documents, software, and hardware.
Version 4.1.1 is not a minor housekeeping update. For digital teams, the single biggest change is that the web and software clauses now require conformance to WCAG 2.2 Level AA instead of WCAG 2.1, along with a significantly reworked set of user-preferences requirements and a broadened scope for real-time communication.
The three-step timeline you need to track
- Publication (done): September 2, 2026. The standard text is final and public.
- Citation in the Official Journal of the EU (expected around November 30, 2026). Only once EN 301 549 v4.1.1 is cited here does it carry the legal “presumption of conformity.” The safe harbor organisations rely on this to demonstrate they meet the EAA.
- Transposition into national law, country by country. Each EU member state must fold the standard into its own regulations, and each sets its own lead times.
The EAA is a directive, not a directly applicable law. The practical compliance date for your organisation ultimately depends on the third step in each country you operate in. But there’s a catch worth flagging to legal and product stakeholders. Some national laws reference EN 301 549 but do not pin a specific version number. In those jurisdictions, the new version can automatically become the operative benchmark. There is no new legislation required. This means your real deadline could arrive sooner than the OJEU citation date suggests.
What EN 301 549 v4.1.1 changes for websites and mobile apps
EN 301 549 v4.1.1 covers ICT broadly (hardware, real-time communications, documents, software), but two clauses matter most if you build or maintain websites and mobile/native apps:
- Clause 9 – Web, which governs web pages and web-based apps.
- Clause 11 – Non-web software, which governs native mobile apps, desktop software, and other non-browser-based software.
Both clauses now point to WCAG 2.2 Level AA as the baseline, up from WCAG 2.1 in the prior version. The standard’s conformance clause (9.6) requires web pages to satisfy the WCAG 2.2 conformance model in full. This includes meeting all success criteria across complete pages and complete processes. It also requires using only accessibility-supported technology. These technologies must not interfere with the rest of the page. This same bar effectively extends to native software through Clause 11. Because of this, mobile app accessibility testing now needs to be scoped against WCAG 2.2 AA specifically, not WCAG 2.1.
The six new WCAG 2.2 success criteria you now have to design and test for
WCAG 2.2 adds six success criteria beyond WCAG 2.1, all of which apply equally to responsive websites and native mobile apps:
| Success Criterion | Level | What it requires |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | A focused element (link, button, form field) can’t be entirely hidden behind sticky headers, footers, cookie banners, or in-app overlays. |
| 2.5.7 Dragging Movements | AA | Any interaction that relies on dragging (reordering lists, sliders, swipe-to-delete) needs a single-pointer alternative, like tap-to-move or explicit buttons. |
| 2.5.8 Target Size (Minimum) | AA | Pointer/touch targets must be at least 24×24 CSS pixels, with defined exceptions (inline text links, essential sizing, spacing offsets). |
| 3.2.6 Consistent Help | A | Help mechanisms must appear in the same relative order/location across pages or screens. |
| 3.3.7 Redundant Entry | A | Information a user already entered in a flow (e.g. a shipping address reused for billing) must be auto-populated or selectable, not re-keyed from scratch. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login and authentication flows that rely on cognitive function tests (remembering a password, solving a puzzle) need an accessible alternative (e.g. copy-paste support, password managers, or biometric options). |
Two things are worth flagging to product and engineering leads:
- These criteria will surface “new” defects in things that used to pass. A component that was WCAG 2.1 AA-conformant last quarter can fail 2.4.11 or 2.5.8 today. That’s a raised bar, not a regression in your product, but it still needs remediation work and QA cycles.
- Design-system-level fixes go furthest. Solving target size, focus visibility, and drag alternatives should happen in shared components. Examples include buttons, cards, list items, and modals. This approach is better than solving them page-by-page or screen-by-screen. The same fix typically covers both your website and your mobile app if they share a design system.
It’s not just WCAG: mind the rest of the standard
A common and costly misconception is treating “WCAG 2.2 AA conformant” as synonymous with “EN 301 549 v4.1.1 conformant.” It isn’t. The standard also includes:
- A substantially reworked Clause 6, covering real-time bidirectional communication (voice, real-time text, video). Its scope has broadened from simple two-way voice. It has evolved into a “Total Conversation” model where voice, real-time text, and video can operate simultaneously in one session. This is directly relevant if your website or app includes chat-with-video support, click-to-call, in-app messaging with RTT, or contact-center integrations. Expect meaningfully more work here than a typical WCAG remediation project.
- Reworked user-preferences requirements (Clause 9.7 for web, equivalent clauses for software), which require that your website or app doesn’t override or block platform-level accessibility settings (colour filters, contrast, text size, pointer size, text cursor) unless doing so is essential to the content’s function.
- EAA mappings in the Annexes, useful for legal and procurement teams building or updating VPATs and EAA conformance statements.
For most website and mobile-app teams, Clause 6 and the hardware clauses will be less relevant. This is true unless your product includes real-time voice, video, or chat features. WCAG 2.2 AA, the user-preferences requirements, and the general/software-specific clauses (Clause 5 and Clause 11) apply broadly.
What should follow: a practical action plan
Keep meeting your current legal obligations while you transition. Don’t let “the new standard isn’t cited yet” become an excuse to pause ongoing WCAG 2.1 / EN 301 549 v3.x work. Layer the following on top:
- Baseline and gap-analyse against WCAG 2.2 AA now. Run automated, manual, and assistive-technology testing across your website and mobile apps. Focus specifically on the six new criteria. Also, consider the reworked user-preferences requirements.
- Prioritise your design system first. Fixing focus visibility, target size, and drag alternatives at the component level resolves many new findings. These include buttons, form controls, cards, carousels, and modals. This approach results in the fewest changes.
- Audit authentication and form flows. Map every login, signup, checkout, and multi-step form for 3.3.7 (Redundant Entry) and 3.3.8 (Accessible Authentication) issues: these tend to be process-level, not component-level, so they need dedicated review.
- Scope real-time communication features separately, and early. If your product has chat, click-to-call, video support, or in-app messaging, treat Clause 6 as its own project. Give it its own timeline. This is because it can involve deeper technical refactoring than typical UI remediation.
- Update your VPATs, accessibility statements, and procurement responses to reference WCAG 2.2 AA and EN 301 549 v4.1.1. Do this once your conformance work is underway. This way, legal and sales teams aren’t caught citing an outdated baseline in RFPs and contracts.
- Communicate the “why” internally. The new criteria will surface defects in previously “passing” components. Set expectations early with engineering and QA. This is a raised bar across the industry. It is not a quality failure in your existing product. This way, remediation gets prioritised rather than deprioritised as “just another accessibility backlog item.”
- Watch your specific national transpositions. If your target markets reference EN 301 549 without a version number, treat your effective compliance date as now. Do not wait for the eventual OJEU citation date.
Why this matters beyond the EU: the global ripple effect
EN 301 549 v4.1.1 is an EU standard, but its reach isn’t limited to EU-headquartered companies, and its influence isn’t limited to Europe.
If you sell into the EU, you’re in scope regardless of where you’re based. The European Accessibility Act applies to any business, whether EU-based or not. The relevance depends on the business offering in-scope products or services. These include e-commerce, banking, e-books, and transport ticketing to customers in the 27 EU member states. A company with EU customers needs to plan for EN 301 549 v4.1.1. It does not matter if they are headquartered in the US, India, or anywhere else. They must do so the same way an EU-based company does.
WCAG 2.2 AA is becoming the common denominator across markets, not just Europe’s. EN 301 549 v4.1.1 adopting WCAG 2.2 AA lines it up more closely with where other major accessibility frameworks are heading:
- United States: ADA Title II and Section 508 requirements are built around WCAG conformance. US organisations serving EU customers now face pressure to move to WCAG 2.2 AA to satisfy both regimes with one build.
- United Kingdom: Public and private sector guidance under the Equality Act 2010 and PSBAR already points to WCAG 2.2 Level AA, matching the new EU baseline.
- India: Standards like IS 17802, GIGW, and SEBI’s accessibility obligations for listed entities are converging on the same WCAG-based approach.
- Asia-Pacific: Australia has previously modelled its own ICT accessibility standard on EN 301 549. As v4.1.1 rolls out, a future revision of Australia’s standard adopting WCAG 2.2 AA is a real possibility worth watching if you operate there.
The practical upshot: build once, to the highest common bar, and you reduce duplicate work everywhere. Teams that design and test to WCAG 2.2 AA as their baseline put themselves in a strong position to meet EN 301 549 v4.1.1. They do this rather than treating each regulation as a separate checklist. This approach also helps them meet US, UK, and Indian requirements from the same underlying codebase and design system. This method is significantly more efficient. It allows the running of a global accessibility program without having to chase each jurisdiction’s rules as they update independently.
Why this matters for procurement, not just engineering
EN 301 549 is already a standard fixture in public-sector and enterprise procurement, not just a technical compliance document. Government agencies, large enterprises, and increasingly private-sector vendors across the EU cite EN 301 549 directly in RFPs.
They mention it in tenders and vendor accessibility questionnaires. They ask suppliers for a VPAT/ACR as supporting evidence. Once v4.1.1 becomes the cited standard, procurement teams will start referencing it by version number in new tenders. They will push back on VPATs that still cite WCAG 2.1 or EN 301 549 v3.2.1.
That has direct implications for anyone who sells software, websites, or apps to EU-based customers, public or private:
- Sales and procurement-response teams need an updated VPAT on hand before it’s asked for. A VPAT/ACR mapped to WCAG 2.2 AA and EN 301 549 v4.1.1 is faster to produce proactively than under RFP deadline pressure. An outdated VPAT can itself become a red flag in a competitive bid.
- “We’re compliant” claims need to specify which version. A vague accessibility statement invites follow-up questions from procurement evaluators; citing the exact standard and version (EN 301 549 v4.1.1, WCAG 2.2 AA) signals that your compliance program is current.
- Vendor risk assessments increasingly include accessibility as a scored criterion, not just a checkbox, particularly for public-sector and regulated-industry buyers. Having documentation ready before the OJEU citation date offers a competitive advantage. It is not just a compliance safeguard.
How Enabled.in can help
Enabled.in is a digital accessibility company. It is built specifically around standards-driven compliance work. This includes auditing, remediating, and documenting conformance for websites, mobile apps, documents, and software. These efforts ensure compliance against WCAG, ADA/Section 508, EN 301 549/EAA, AODA (Canada), and RGAA (France). For teams navigating the move to EN 301 549 v4.1.1, that translates into concrete support at each stage of the plan above:
- Gap analysis against WCAG 2.2 AA and EN 301 549 v4.1.1. This includes combining automated scanning, expert manual evaluation, and real-user testing by people with disabilities. It covers the six new success criteria: focus visibility, drag alternatives, target size, consistent help, redundant entry, and accessible authentication. These assessments are performed across both web and native mobile apps.
- Design-system-level remediation guidance. Fixes to shared components (buttons, cards, modals, form controls) resolve issues across your entire website or app. This avoids addressing them screen by screen.
- Assistive technology and cross-device testing include screen readers, screen magnifiers, voice input, and alternative navigation. These tools ensure that fixes actually work for real users, not just automated checkers.
- Authentication and form-flow review for 3.3.7/3.3.8 compliance across login, checkout, and onboarding journeys.
- VPAT preparation and EAA/EN 301 549 conformance documentation is mapped to the standard’s updated Annexes. This supports procurement, legal, and sales conversations.
- Procurement-ready documentation and RFP support. Your sales and bid teams will have a current VPAT/ACR on hand. An accessibility statement will be ready before a tender or vendor questionnaire asks for one. This prevents scrambling to produce it under deadline pressure.
- Training and ongoing governance support will help your product, design, and engineering teams catch new-criteria issues before they ship. This reduces the need to rely solely on periodic audits.
- Multi-market compliance support beyond the EU, covering ADA Title II and Section 508 (US). It also covers the Equality Act and PSBAR (UK). Additionally, it includes SEBI/IS 17802/GIGW (India). This ensures that a single WCAG 2.2 AA baseline can support compliance across all your markets, not just Europe.
If your website or mobile app hasn’t yet been evaluated against WCAG 2.2 AA and EN 301 549 v4.1.1, the practical move is to start the gap analysis now. Do this before the standard is cited in the Official Journal. This method ensures that remediation work begins early. It will be underway by the time it becomes the enforceable benchmark in your markets, wherever your customers are.
Request a WCAG 2.2 AA / EN 301 549 v4.1.1 gap analysis →
Reach to us:
Need support with accessibility auditing, remediation or VPAT/ACR preparation?
Contact Enabled.in Digital Accessibility Services
Email: sathasivam@enabled.in