If you sell or provide digital services to EU consumers, accessibility is no longer a nice upgrade. It is a legal requirement that now sits alongside your security and privacy checks. The European Accessibility Act applies from 28 June 2025, bringing common rules for many consumer products and services across the EU, including e-commerce services delivered through websites and apps. (AccessibleEU)
What the EAA actually covers for websites and apps
The EAA is a single EU directive that sets accessibility requirements for products and services that matter most to disabled people and older users. It covers areas like banking services, telecoms, transport ticketing and check-in, e-books and readers, and e-commerce services. For digital teams, the most immediate implication is that customer-facing websites and apps used to sell to EU consumers must meet functional accessibility outcomes defined in the law. The directive is implemented through national laws in each Member State, which handle monitoring and penalties. (European Commission)
There is a separate EU law for the public sector, the Web Accessibility Directive. That one requires public bodies to make their websites and mobile apps accessible and points to a harmonised European standard for the technical details. Private companies are not covered by that public sector directive, but they are brought into scope by the EAA when they provide in-scope products and services, including e-commerce. (Digital Strategy)
EN 301 549 and the link to WCAG
The technical glue for EU accessibility policy is the European standard EN 301 549. It defines accessibility requirements for ICT products and services and has been referenced by the public sector directive for years. EN 301 549 builds on WCAG, and recent versions add some requirements that go beyond WCAG 2.1 for specific cases such as audio and video. Expect the same standard to underpin how EAA conformance is assessed in practice. (ETSI)
WCAG 2.2 is now the current W3C recommendation. It is backward compatible with WCAG 2.1, which means a site that conforms to WCAG 2.2 also conforms to 2.1. That is useful because EU references and testing methods often name 2.1, while many teams now target 2.2 to future-proof their work. In short, if you plan to meet WCAG 2.2 Level AA across your templates, you will satisfy the WCAG 2.1 foundation that EN 301 549 expects, and you will pick up the newer user-focused criteria such as focus not obscured and target size minimum. (W3C)
Timelines, exemptions, and the 2030 question
The EAA applies from 28 June 2025. Member States enforce it through national rules and market surveillance authorities. Many teams ask about a supposed 2030 website deadline. The reality is more nuanced. The directive sets a transitional period that runs to 28 June 2030 in which service providers may continue to provide their services using non-compliant products they were already using before 28 June 2025. This transition primarily addresses physical products used to deliver services, such as payment terminals or kiosks. Member States may also allow existing self-service terminals to run until the end of their useful life, up to 20 years. The key point for digital is that services you provide to consumers after 28 June 2025 are expected to be accessible, and new products placed on the market after that date must meet the rules. (EUR-Lex)
Microenterprises that provide services can be out of scope under the directive. A microenterprise is a business with fewer than ten employees and turnover or balance sheet total under 2 million euros. Some national laws give these smallest operators relief, while others set their own wrinkles. Always check the local implementation where you trade. (ccpc.ie)
What European Accessibility Act website compliance looks like in practice
Compliance is not a checkbox audit once a year. Treat it as a working standard across design, content, and engineering.
Set a clear target and scope
Aim for WCAG 2.2 Level AA across your website and app templates. List your customer journeys and which views support them, such as listing pages, product detail pages, checkout, account, help, and legal content. If you operate a marketplace or SaaS product, include in-product flows like onboarding and billing. WCAG gives you a stable yardstick. EN 301 549 gives you the EU context that regulators use when they assess conformance. (W3C)
Run a focused accessibility audit
Combine automated scans with manual testing. Automated tools catch low-hanging issues such as missing names for controls, contrast defects, and heading order. They do not judge whether your focus indicators are visible in real use or whether a custom widget behaves like a native control. Use screen readers and keyboard testing to validate the basics. NVDA on Windows and VoiceOver on macOS or iOS cover a large share of real users and will expose the typical gaps in labels, states, and focus management. The law does not require a specific tool, but it expects a functional outcome that disabled users can actually achieve. (W3C)
Fix the basics that block users
Start with the issues that prevent someone from using your site without a mouse or without vision. Provide visible focus states that are not obscured by sticky elements. Ensure that keyboard users can tab into menus and dialogs and then move through items logically. Add programmatic names to links and buttons so they make sense out of context. Make form errors specific and announce them to assistive technologies. These steps map directly to WCAG 2.2 AA and will improve the experience for everyone, not just people using screen readers or magnifiers. (W3C)
Design choices that make compliance easier
Pick colour pairs that pass contrast without relying on borderline values. Use system fonts or a well-hinted typeface to keep characters clear at small sizes. Keep icons accompanied by text where meaning matters. Avoid custom components that reinvent native patterns unless you also recreate the expected keyboard behaviour and ARIA semantics. Every time you keep a native element, you avoid a round of aria attributes and edge cases. These choices reduce the audit burden and lower your long-term risk.
Content patterns that help screen readers
Write unique, descriptive page titles and headings that mirror the content. Use meaningful link text rather than vague phrases like “Learn more”. Provide alt text that explains the function of an image, not only what it looks like. For video and audio, provide captions and transcripts. When you publish tables, include headers and summaries that explain how to read the data. These habits meet the legal requirement to provide accessible information and they improve search and conversion for everyone. (W3C)
Building EAA-ready sites on WordPress and custom stacks
Many teams ship on WordPress or a custom React or Next.js stack. The moves are similar, but a few details differ.
WordPress
Start with a block theme that respects accessibility from the base. Avoid plugins that inject inaccessible widgets such as heavy sliders with weak keyboard support. Use the Site Editor to define design tokens in theme.json so colours and typography stay within your contrast rules. Where you need interactive elements such as accordions or tabs, prefer native details and summary or well-maintained patterns that already reflect ARIA roles and keyboard support. Dequeue plugin assets on pages where they are not used to keep the DOM simple and predictable for assistive tech.
Custom React or Next.js
Favour semantic HTML in your components. Reach for button and a tags with proper attributes rather than divs with click handlers. Build accessible modals, menus, and comboboxes with a tested library and verify behaviour with keyboard and screen readers. Server render critical content so screen readers have something meaningful to parse even on a poor connection. Keep your focus management explicit when you change routes so users do not get stranded at the top of the page with no cue about what changed.
Governance that keeps you compliant after launch
Accessibility fails when it is owned by one person or left to the end of a sprint. Put in place light processes that prevent regressions.
Create a short checklist that sits in your definition of done. Include contrast checks for new components, keyboard testing of interactive elements, and alt text for images that carry meaning. Add automated tests for recurring patterns, such as axe rules in CI, and fail builds on critical issues that are easy to detect. Train content editors on headings, link text, and media alternatives so accessibility does not degrade with routine updates. Review your top templates each quarter with a manual pass that includes keyboard and screen reader testing.
If you work across borders, document which national rules implement the EAA for your customers. The directive sets the baseline, while the real monitoring and penalties sit inside each Member State. Keep a list of the authority contacts alongside your privacy and cookies register. (Bird & Bird)
Frequently raised legal points
Do we need to meet WCAG 2.2 or 2.1. EU materials and EN 301 549 commonly reference WCAG 2.1, but WCAG 2.2 is backward compatible. If you meet 2.2 AA you also meet 2.1 AA, and you give users better focus handling, larger target sizes, and fewer repetitive form entries. Many organisations choose 2.2 AA as their internal bar for that reason. (W3C)
What happens between 2025 and 2030. New products placed on the market after 28 June 2025 must be accessible. Services provided to consumers after that date must be accessible. There is a limited transitional period in which service providers may continue to provide services using products they already used before that date, and self-service terminals may be allowed to run until the end of their useful life up to a 20-year cap. Your website and app should be built to be accessible now rather than assuming a 2030 digital grace period. (EUR-Lex)
Are microenterprises exempt. Microenterprises that provide services can be out of scope under the directive, although there are differences in national transpositions. If you are close to the threshold or you plan to scale, it is safer and more cost effective to build accessibility in rather than retrofitting later. (ccpc.ie)
A simple starting plan for the next four weeks
Week 1. Baseline audit on your top ten templates. Include automated scans and manual keyboard plus screen reader checks. Record issues and map each to a WCAG 2.2 criterion. (W3C)
Week 2. Fix the blocking defects that stop basic use. Prioritise focus visibility, keyboard traps, missing names for controls, and form error messaging. Validate your colour tokens.
Week 3. Address patterns that repeat. Replace custom widgets with accessible versions. Standardise heading levels across templates. Add captions to key videos and alt text to core imagery.
Week 4. Document an internal standard. Set WCAG 2.2 AA as your target. Add a short accessibility checklist to your definition of done. Wire an automated ruleset into CI and book a quarterly manual review.
The bottom line
European Accessibility Act website compliance is not a legal footnote. It is a practical way to ensure that people can find products, complete tasks, and get help regardless of how they access the web. The law now expects it across much of the private sector. The standards are clear, the testing techniques are mature, and the fixes often improve conversion and support. Build to WCAG 2.2 AA, use EN 301 549 as your reference point, and treat accessibility like you treat security and privacy. If you do that, you will meet legal expectations in 2025 and you will make a better site for everyone. (ETSI)
Also Read: Vital Elements of A Website Design
