Since 28 June 2025, the European Accessibility Act (EAA) has required many consumer-facing digital products and services sold in the European Union to be accessible to people with disabilities. For product and engineering teams, this turned accessibility from a nice-to-have into a market access requirement, enforced by national authorities in every Member State. In September 2026 the picture sharpened further when European standards bodies published EN 301 549 V4.1.1, which moves the technical baseline to WCAG 2.2. Many organizations still treat accessibility as a one-off audit followed by a backlog of tickets that never quite closes. This playbook explains what the EAA expects from web and mobile applications, how the standards fit together, and how to build accessibility into the way you design, build and release software so compliance holds up release after release.
What the European Accessibility Act Covers
The EAA (Directive (EU) 2019/882) harmonizes accessibility requirements for a defined list of products and services across the EU. Member States transposed it into national law, and its requirements have applied to new products and services since 28 June 2025. According to the European Commission, the covered areas include computers and operating systems, smartphones, self-service terminals such as ATMs and ticket machines, e-readers, telephony services, access to audiovisual media services, passenger transport services for air, bus, rail and waterborne travel, consumer banking services, e-books and e-commerce.
For application teams, the digital service categories matter most. In practice, the following are almost always in scope when offered to consumers in the EU:
- E-commerce websites and apps, including product pages, carts, checkout and account management.
- Online and mobile banking for consumers, including onboarding, payments and card management.
- Websites, apps, e-ticketing and real-time travel information for passenger transport.
- E-book platforms and the dedicated software used to read them.
- Communication services and the apps used to access audiovisual media services.
Location of the company does not determine scope. A business headquartered in North America or Asia that sells to consumers in the EU is covered for those services. There is an exemption for microenterprises providing services, generally defined as organizations with fewer than 10 employees and annual turnover or balance sheet not exceeding EUR 2 million. Operators can also claim that a requirement would fundamentally alter the service or impose a disproportionate burden, but these claims must be assessed and documented, and they are not a general escape hatch.
Timelines and Transitional Periods
New in-scope products and services have had to comply since 28 June 2025. Transitional arrangements allow certain existing services and contracts to continue until 28 June 2030, after which the requirements apply across all in-scope products and services. For digital teams, the practical reading is simple: any new feature, redesign or new app released today should be accessible, and legacy surfaces need a credible remediation plan well before 2030. Waiting is risky because enforcement responsibility sits with national market surveillance authorities that can investigate complaints, and penalties are set nationally.
How the Standards Fit Together: WCAG 2.2 and EN 301 549
The EAA defines functional accessibility requirements in legal language, such as making services perceivable, operable, understandable and robust. It does not prescribe code-level rules. That is the role of harmonized standards. EN 301 549 is the European standard for accessibility of ICT products and services, and conforming to a version cited in the Official Journal of the EU gives a presumption of conformity with the corresponding legal requirements.
According to Ireland’s National Disability Authority, EN 301 549 V4.1.1 was published on 2 September 2026, replacing V3.2.1 from 2021. Its most important change is that the baseline for web content, non-web documents and software moves from WCAG 2.1 to WCAG 2.2 Level AA. It is also the first version written with the EAA in mind, including an annex that maps its clauses to the Act’s requirements. The new version gains its legal effect once cited in the Official Journal; the NDA reported that citation was expected on 16 December 2026, and until then V3.2.1 remains the cited version. Law firm Davis Wright Tremaine similarly notes that the presumption of conformity depends on that citation.
For planning purposes, the conclusion is clear: build to WCAG 2.2 Level AA now. Designing to WCAG 2.1 today means redoing work within months. WCAG 2.2 added several success criteria at Levels A and AA that affect common interface patterns:
- Focus Not Obscured (Minimum): keyboard focus must not be fully hidden by sticky headers, cookie banners or chat widgets.
- Dragging Movements: any function that uses dragging, such as sliders, kanban boards or map panning, needs a single-pointer alternative.
- Target Size (Minimum): interactive targets need adequate size or spacing, which matters for icon buttons and dense mobile layouts.
- Consistent Help: help mechanisms such as contact links or chat should appear in a consistent place across pages.
- Redundant Entry: users should not have to re-enter information they already provided in the same process, for example in multi-step checkouts.
- Accessible Authentication (Minimum): login must not depend on cognitive tests such as memorizing or transcribing codes, unless alternatives like paste support, password managers or passkeys are allowed.
Native mobile apps are covered too. WCAG is written for web content, but EN 301 549 applies equivalent requirements to non-web software, so iOS and Android apps need proper accessibility labels, support for screen readers such as VoiceOver and TalkBack, dynamic text sizing, sufficient contrast and logical focus order.
Beyond the Interface: Information and Documentation Duties
Compliance is not only about pixels and markup. Service providers must explain how their service meets the accessibility requirements, typically in their general terms and conditions or an equivalent, publicly available accessibility statement. Support channels, documentation and customer communications also need to be accessible. If your app links to PDFs for terms, statements or invoices, those documents fall under the same expectations. Teams should also keep internal records: audit reports, remediation plans, conformance decisions and any disproportionate burden assessments. If an authority asks questions, documented evidence of a managed process is far more persuasive than a claim of compliance.
Step-by-Step Compliance Playbook
The following sequence works for organizations with one flagship app as well as for portfolios of dozens of digital products.
- Inventory and scope. List every consumer-facing website, web app, mobile app, kiosk interface and digital document channel used in the EU. Map each to EAA service categories and identify any microenterprise or transitional considerations with legal counsel.
- Prioritize critical journeys. For each product, identify the user journeys that matter most: sign-up, login, search, product detail, checkout, payments, account settings, support. These are where barriers cause the most harm and the most complaints.
- Audit against WCAG 2.2 AA. Combine automated scanning with expert manual testing and testing by people with disabilities using assistive technologies. Automated tools find only a portion of issues; keyboard traps, confusing focus order, meaningless link text and unusable custom widgets typically require human evaluation.
- Triage by severity and reach. Classify issues by user impact (blocking, serious, moderate) and by how many screens share the defect. Shared components are the highest-leverage fixes.
- Fix the design system first. Remediate buttons, form fields, modals, menus, date pickers, carousels and data tables in your component library. A single accessible component can resolve hundreds of page-level issues.
- Remediate journeys and content. Apply component updates, fix page-specific issues, add text alternatives, correct heading structures and repair documents.
- Publish your accessibility information. Write a clear statement covering conformance status, known limitations, alternatives and a way for users to report barriers.
- Embed prevention. Add accessibility to definitions of done, design reviews, code review checklists and CI pipelines so new regressions are caught before release.
Engineering Accessibility into the Delivery Pipeline
Audits find problems; pipelines prevent them. Sustainable compliance depends on making accessibility a property of the delivery process rather than a periodic project.
Design and Design Systems
Accessibility decisions start in design tools. Define color tokens that meet contrast requirements, specify focus states for every interactive element, set minimum target sizes, and document keyboard interactions for complex components. Annotate designs with heading levels, landmarks and reading order so developers do not have to guess. Treat the design system as the primary accessibility asset: every component should have documented accessibility behavior and tests.
Development Practices
Prefer native HTML elements and platform controls over custom widgets; a real button or select comes with keyboard and screen reader support for free. When custom components are necessary, follow established ARIA authoring patterns and test them with real assistive technologies. In single-page applications, manage focus on route changes and announce dynamic updates such as form errors or cart changes. On mobile, use platform accessibility APIs rather than overlay workarounds.
Automated and Manual Testing
Run automated accessibility checks in unit and component tests and in end-to-end tests of key journeys, and fail builds on new serious violations. Add visual regression checks for focus indicators and zoom behavior. Schedule periodic manual testing with screen readers, keyboard-only navigation, voice control and magnification. Include people with disabilities in usability testing; they find issues that checklists miss. Avoid relying on accessibility overlay widgets as a compliance strategy, since they do not fix underlying code and are widely criticized by disability advocates.
Ownership, Vendors and Metrics
Accessibility decays without an owner. Assign an accountable lead for each product, typically the product owner, supported by a small central accessibility function that maintains standards, tooling and training. Write accessibility requirements into contracts with agencies and software vendors, and ask third-party providers of payment, chat, video and consent components for their own conformance reports before you integrate them. Track a handful of metrics that show whether the program is working: open issues by severity on critical journeys, the share of design system components with documented and tested accessibility behavior, the number of new violations caught in CI versus found in production, and the time taken to resolve user-reported barriers. Reviewing these numbers alongside other quality indicators in regular product governance keeps accessibility visible to leadership and prevents it from becoming a compliance task that only surfaces when a complaint arrives. Training matters too: short, role-specific sessions for designers, developers, testers and content authors are more effective than generic awareness courses.
Treat accessibility as a quality attribute of your design system and pipeline, not as an audit you pass once. Build to WCAG 2.2 AA today and every new release reduces risk instead of adding to it.
Worked Example: Remediating a Retail Checkout
Imagine a hypothetical mid-sized online retailer serving customers in several EU countries through a web storefront and native mobile apps. An initial audit of its five most important journeys against WCAG 2.2 AA finds several hundred issues. On closer analysis, most trace back to about 20 shared components: a custom dropdown without keyboard support, form fields whose error messages are not announced to screen readers, icon-only buttons without accessible names, a date picker that works only with a mouse and a sticky promotional banner that hides keyboard focus.
The team spends the first six weeks fixing these components in the design system and releasing them across the web and mobile codebases. A second phase addresses journey-specific problems: the checkout requires customers to retype their address for billing, violating Redundant Entry, so the team adds a “same as delivery address” option. The login flow blocks pasting into the one-time code field, which conflicts with Accessible Authentication, so paste support and passkeys are enabled. In parallel, the team adds automated checks to its pipeline, publishes an accessibility statement and sets up a feedback channel. After remediation, a follow-up audit shows the critical journeys substantially conformant, with remaining issues logged, prioritized and dated.
The key decision in this example is sequencing. By fixing shared components first, the team reduces the issue count far faster than it could by working page by page, and it prevents the same defects from reappearing in new features.
Common Pitfalls to Avoid
- Treating a passing automated scan as proof of compliance, when many criteria need human judgment.
- Auditing the marketing website but ignoring the logged-in app, mobile apps and transactional documents where most customer tasks happen.
- Remediating pages one by one instead of fixing shared components and templates.
- Building to WCAG 2.1 when the harmonized standard is moving to WCAG 2.2.
- Forgetting third-party components such as payment widgets, chat tools and consent banners, which are part of your service from the user’s perspective.
- Assuming non-EU headquarters or B2B framing removes obligations for consumer-facing services sold in the EU.
- Leaving accessibility ownership undefined, so fixes decay after the initial project ends.
Outlook: Accessibility as a Continuous Obligation
The EAA is part of a broader direction in EU digital regulation toward user rights and product quality obligations. As national authorities build enforcement practice and EN 301 549 V4.1.1 becomes the cited standard, expect complaints-driven investigations, procurement requirements and customer due diligence to increasingly reference WCAG 2.2. AI will also play a growing role: AI tools can help generate alternative text drafts, suggest fixes and detect issues at scale, but human review remains necessary, especially for meaning and context. Organizations that build accessibility into their platforms now will find each new regulation or standard update incremental rather than disruptive.
Conclusion
The European Accessibility Act has made accessibility a condition of doing digital business with EU consumers. The technical path is well defined: WCAG 2.2 Level AA through EN 301 549 V4.1.1, applied to websites, web apps and native mobile apps alike. The organizational path is where most teams struggle. Start with an inventory and audit of critical journeys, fix your design system before individual pages, publish clear accessibility information and embed testing into your pipeline. Done this way, accessibility stops being a compliance fire drill and becomes a quality standard that improves usability for every customer.
How Hanoi Technology Can Help
Hanoi Technology helps product teams audit and remediate web and mobile apps against WCAG 2.2, rebuild accessible design systems and add automated accessibility testing to CI/CD.