European Accessibility Act: June 2025 Deadline

In January 2025, the European Accessibility Act stopped being a far-off date in a compliance spreadsheet and became a deadline teams could feel. The Act was adopted back in 2019, EU member states transposed it into national law by June 28, 2022, and from June 28, 2025 those national laws start being enforced. For a lot of product teams, this is the first piece of digital-accessibility law with real consumer-facing teeth that applies to them—and the runway is now measured in months, not years. As a UI/UX designer at Softechinfra, I spend a lot of my time turning regulations like this into something a designer and a developer can actually do on a Tuesday. This guide is that translation: who is in scope, what "compliant" concretely means, and a checklist you can work through whether you read this in 2025 or in 2027.

What the EAA Actually Requires

The European Accessibility Act is a single law with a deceptively broad reach. It sets common accessibility requirements for a defined set of products and services so that people with disabilities can use them on equal terms across the EU single market. The Act itself describes outcomes—perceivable, operable, understandable information and interfaces—rather than line-by-line technical rules. The technical detail comes from the harmonised European standard EN 301 549, which in turn leans heavily on the Web Content Accessibility Guidelines.

For digital teams, the practical translation is simple to state and harder to do: your websites, mobile apps, and the services delivered through them need to meet WCAG 2.1 Level AA. That is the bar EN 301 549 effectively points at for web and app content, and it is the bar you should design and test against.

Who Is In Scope (and Who Has Breathing Room)

Scope is where most teams either panic unnecessarily or relax when they should not. The Act covers specific products and services placed on the EU market: e-commerce, consumer banking, e-books and their reading software, ticketing and transport services, telephony and messaging services, audiovisual media access services, and self-service terminals among others.

A few realities decide whether June 28, 2025 is your problem:

• You sell to or serve EU consumers. Where your company is incorporated matters less than where your customers are. A non-EU business offering covered services to people in the EU can still be in scope.
• Your product is a covered service. E-commerce checkout, consumer banking flows, and the apps that deliver them are squarely named. Pure internal tools and B2B-only software are treated differently.
• You are not a micro-enterprise providing services. The Act carves out microenterprises—roughly, fewer than 10 staff and a small turnover—that provide services, though the exemption is narrower for products. Do not assume it applies without checking your national transposition.

If you are out of scope today, build to the standard anyway. Scope tends to widen over time, public-sector accessibility rules already bind many vendors through procurement, and retrofitting accessibility into a mature product is dramatically more expensive than building it in. The framework below is worth running regardless of which side of the line you sit on.

The WCAG 2.1 AA Checklist, Organised by POUR

WCAG is organised around four principles—Perceivable, Operable, Understandable, Robust, or POUR. Memorising fifty success criteria is a losing game; understanding the four buckets and the handful of issues that cause most real-world failures is not. Here is the working checklist I hand to teams.

Perceivable — users can sense the content.

• Every meaningful image has descriptive alt text; decorative images are marked so screen readers skip them.
• Text contrast meets at least 4.5:1 for body copy and 3:1 for large text and meaningful UI components.
• Video has captions and audio content has transcripts or audio description where needed.
• Content reflows and stays usable at 200% zoom and on small screens without horizontal scrolling.
• Information is never conveyed by colour alone—pair it with text, icons, or patterns.

Operable — users can navigate and act.

• Everything works with a keyboard alone, with no traps that strand the focus.
• A visible focus indicator shows where the keyboard user is at all times.
• Tap and click targets are large enough and not crowded together.
• Time limits can be extended or turned off; nothing critical flashes more than three times a second.

Understandable — content and behaviour are predictable.

• Form fields have visible, programmatically associated labels—not just placeholder text.
• Errors are identified in text, explained clearly, and easy to recover from.
• Navigation and component behaviour stay consistent across the product.

Robust — assistive tech can parse it.

• Semantic HTML first; ARIA only to fill genuine gaps, and correctly.
• Custom components expose the right name, role, and value to assistive technology.
• Status messages and dynamic updates are announced without stealing focus.

A handful of issues account for the bulk of failures in audits: missing form labels, low colour contrast, images without alt text, content that is unreachable by keyboard, and links or buttons whose purpose is invisible to a screen reader. Fixing those five categories well moves most products most of the way to AA. We go deeper on the underlying criteria in our WCAG compliance guide, and much of the "understandable" bucket overlaps with good UX writing and microcopy—clear labels and recoverable errors are an accessibility feature as much as a usability one.

A Realistic Preparation Plan

You cannot bolt on accessibility the week before a deadline, but you can make orderly progress in a few focused sprints. This is the sequence we use.

1. Audit honestly. Run an automated scan (axe, Lighthouse, WAVE) to catch the obvious 30–40%, then do a manual pass: keyboard-only navigation, a screen-reader walkthrough of your top flows, and a zoom test. Automated tools never find everything—budget for the manual work.
2. Triage by user impact and reach. Score findings the way you would any backlog: a contrast failure on the checkout button outranks a missing alt tag on a footer decoration. Fix what blocks core journeys first.
3. Fix the systemic causes, not just instances. If buttons fail contrast in one place, they probably fail everywhere. Correct the design tokens and shared components so the fix propagates instead of playing whack-a-mole.
4. Retest with real assistive technology. Re-run the automated scan, then re-walk the priority flows with a screen reader. Confirmation by tooling alone is not confirmation.
5. Document conformance. Keep an accessibility statement and, where relevant, a conformance record. It signals good faith and is exactly what you will be asked for.

Build It In, Don't Bolt It On

The teams that handle accessibility cheaply are the ones that stopped treating it as a separate workstream. On AppliedView, the accessibility work that mattered most was upstream: a colour palette validated for contrast before a single screen was designed, a component library where every interactive element shipped with correct focus states and ARIA semantics, and form patterns with proper labels and error handling baked in. Because those decisions lived in the design system, individual screens inherited them for free—the expensive retrofit never happened because there was nothing to retrofit.

That is the lesson worth carrying past June 2025. The EAA deadline is a forcing function, but the durable win is making accessibility a default of how you build, the same way we treat it across our web development work.

What to Do This Quarter

If the deadline applies to you and you have not started, the path is straightforward: confirm your scope against the national law where your customers are, audit your top three user journeys this sprint, fix the systemic contrast, label, and keyboard issues next, and put an accessibility statement in place. If you are not in scope, run the same checklist anyway—you will end up with a product that is faster to maintain and friendlier to far more users than the law happens to name.

The regulation has a date on it. The right way to build does not. Either way, the work is the same, and it is work you can start this week.