Website Accessibility Compliance: What the European Accessibility Act Changes for Your Stack

The deadline that already passed

On 28 June 2025, the European Accessibility Act became enforceable across the European Union. The Act — Directive (EU) 2019/882 — had been on the books since 2019, with years of lead time, but many website owners treated it as a distant legal abstraction until the transition period actually ended.

What makes this directive different from earlier web accessibility rules is its scope. It explicitly covers consumer services, and e-commerce is on the list alongside banking, transport and e-books. It also applies to businesses selling into the EU market regardless of where the company itself is registered. A store outside the EU that serves EU consumers is inside the directive’s reach; accessibility requirements follow the customer, not the server location.

Enforcement is national. Each member state transposed the directive into its own law, with its own supervisory authority and its own penalty structure, so the practical exposure depends on where your customers are. The directive also contains limited exemptions that member states implement differently, which means genuine scope questions — Is our service covered? Are we exempt? — belong with legal counsel, not with a blog post. What a development team can and should own is the technical side: building and maintaining a website that meets the requirements the law points to.

What EN 301 549 actually asks for

The directive does not contain a checklist of its own. For websites, the practical reference is EN 301 549, the harmonised European standard for ICT accessibility, whose web requirements incorporate WCAG 2.1 Level AA. Conformance with the harmonised standard creates a presumption of conformity with the directive’s relevant requirements — the standard is how a technically ambiguous legal text becomes something a developer can implement and test against.

In concrete terms, the WCAG 2.1 AA baseline touches things most business sites get wrong somewhere:

• Perceivable content — real text instead of text baked into images, alt text that describes function rather than decoration, sufficient contrast between text and background, captions and transcripts for media.
• Operable interfaces — every action reachable with a keyboard alone, visible focus indicators, no interactions that trap keyboard users, no loss of content on reflow or zoom.
• Understandable structure — a logical heading hierarchy, descriptive link text, form labels that persist on screen, input errors described in text rather than by color alone.
• Robust markup — valid, semantic HTML that assistive technology can parse, with names, roles and values exposed correctly for custom components.

None of this is exotic. Most failures we see in audits are mundane: a hamburger menu that cannot be opened without a mouse, an overlay dialog that swallows keyboard focus, a brand palette whose button text falls below contrast thresholds, a contact form whose labels disappear on input.

Why an overlay is not a strategy

The moment compliance obligations became real, a market appeared: JavaScript “accessibility overlay” widgets that promise WCAG conformance by injecting a single script tag. The pitch is attractive because it requires no design changes, no template work and no content discipline.

It does not work that way. A large share of WCAG success criteria — heading structure, meaningful link text, logical reading order, correct form labeling — describe properties of your markup and content that must exist before any script runs. An overlay that rewrites the DOM after the fact cannot reliably reconstruct information that was never there, and assistive technology users frequently report that injected toolbars interfere with their own, better-configured tools. Overlay products themselves typically stop short of guaranteeing legal compliance in their own terms of service.

Automated tooling still has a role — scanning for missing alt attributes, contrast failures and broken landmarks catches real defects quickly. But automated rules evaluate only a minority of the success criteria. The rest require a human being to navigate the site with a keyboard, listen to it with a screen reader, and judge whether the experience actually works. Budget accordingly.

Where each platform puts the work

Accessibility is platform-neutral in principle and platform-specific in practice. The four stacks YCTheme builds on distribute the same workload very differently.

WordPress. Core WordPress outputs largely sound markup, and the official theme directory runs an “accessibility-ready” review process with published guidelines a theme must pass before it can carry the tag. That tag is a floor, not a ceiling: it is the theme author’s build that gets reviewed, not your site after you install a page builder, a form plugin and a slider on top of it. The plugin periphery is where WordPress accessibility goes to die — widgets and blocks that emit non-semantic markup, override focus styles, or inject overlays of their own. If your site runs on a heavily extended WordPress setup, the audit should start with the plugin list, not the theme. We cover that discipline as part of our WordPress development service, where the question “which of these plugins emits accessible markup” is asked before installation, not after a complaint.

Joomla. Joomla’s greatest structural advantage here is the template override system: for any component output that fails an audit, an integrator can replace the markup without hacking core. The burden therefore lands on whoever builds the template — a well-built Joomla template with semantic overrides can be brought to conformance efficiently, while a cheap one baked with div soup can resist every fix. Joomla sites tend to have leaner extension stacks than WordPress sites, which reduces the surface that third-party code controls.

TYPO3. TYPO3 is built around integrator-defined content structures, which is exactly what governed accessibility work wants: the system that renders headings, lists and semantic elements is configured centrally, not assembled ad hoc by editors. The ecosystem also ships tooling — there is an accessibility checker extension for TYPO3 that evaluates rendered frontend output against accessibility rules, which fits naturally into an integrator workflow. The cost of that discipline is the same one described in our CMS selection framework: TYPO3 assumes professional involvement, and its accessibility ceiling is set by the integrator’s competence, not by the platform.

Shopify. Shopify occupies a distinctive position because the platform publishes its own accessibility statement covering its services — but that statement covers Shopify the product, not your store. Your theme, your product content, your alt text and your third-party apps are your responsibility, and the merchant is the party the directive’s e-commerce provisions reach. Two structural facts shape the work: checkout markup is largely platform-controlled, which is good news (Shopify maintains it and it is generally well-built), while the storefront theme and app-embedded widgets are where merchant-side failures concentrate. Stores accumulate app-injected scripts the way WordPress sites accumulate plugins, and leftover app code in themes creates both performance and accessibility debt — a problem we deal with regularly through our Shopify development service, and one that overlaps with the performance work described in our Shopify theme performance guide. More platform context is on the Shopify platform page.

The audit that produces real results

A compliance effort that is more than theater follows a sequence roughly like this:

1. Inventory the templates and components. List every page template, block type, form and interactive widget the site actually renders. Audits fail when they sample the homepage and stop; the failures live in filtered views, checkout steps, modals and cookie banners.
2. Run automated scans, then discard the confidence they offer. Use them to enumerate mechanical defects — missing labels, contrast ratios, missing alt text — and as a regression check for later. Do not use them as proof of anything.
3. Test manually where automation cannot. Navigate the full purchase or inquiry path with the keyboard alone. Listen to key flows with a screen reader. Zoom to 200% and check for content loss. These sessions find the failures that generate actual complaints.
4. Fix by layer, not by instance. A contrast failure is a design token problem; a missing form label is a component problem. Fixing the layer repairs every page that uses it, and prevents the defect from returning with the next feature.
5. Write the accessibility statement, and mean it. Publish a statement describing your conformance target, known limitations and a feedback channel. It signals good faith to regulators and gives users with problems a route that is not a lawsuit.

Accessibility work compounds

The same properties that make a site accessible — semantic structure, real text, logical headings, descriptive links — are the properties search engines and generative engines rely on to parse and retrieve content. This overlap is one of the reasons we treat accessibility as part of the same content-quality discipline discussed in our article on SEO and GEO for website content, rather than as a separate legal checkbox.

There is also a build-versus-extend angle. Teams that rely on prebuilt page-builder sections inherit markup they never reviewed, and the accessibility of the result is whatever the vendor shipped — a tradeoff examined in our comparison of page builders and custom themes. Custom markup is more expensive to create and cheaper to stand behind.

A deadline is not a finish line

The most useful mental shift is to stop treating 28 June 2025 as a finish line. Content teams publish new pages weekly, marketing installs new widgets monthly, redesigns re-theme templates yearly — each of those events can reintroduce failures. Accessibility conformance behaves like security in this respect: it is a property of your process, not a certificate you earn once.

Practically, that means folding accessibility checks into the workflows that already exist: design reviews check contrast and focus states, content reviews check heading structure and alt text, release checklists include a keyboard pass on new interactive components, and periodic audits — like the ones described above — verify that the sum has not drifted. A website that reaches EN 301 549 conformance and stays there is not the one that bought a widget. It is the one whose platform, template structure and editorial habits make conformance the path of least resistance.