European Accessibility Act 2025: A Remediation Plan for SaaS Teams Past the Deadline
The European Accessibility Act enforcement date passed in June 2025. If your SaaS product serves consumers or B2B users in the EU and you have not yet done an accessibility audit, you are past the deadline - not approaching it. That changes the calculus. The goal now is not a theoretically perfect WCAG 2.2 AA implementation; it is a credible, demonstrable improvement plan that shows you are aware of the gaps and actively closing them.
This post gives you the triage-first remediation approach: what auditors actually test for, which issues carry the most legal and user risk, and how to publish an accessibility statement that is defensible rather than aspirational.
What the EAA Actually Requires
The European Accessibility Act applies to products and services placed on the EU market after June 28, 2025, and sets WCAG 2.1 AA as the baseline technical standard. In practice, national transposition laws (such as Germany's BFSGV, France's RGAA, and Austria's WZG) add specifics, but the common thread is that digital products - including web applications and mobile apps - must be perceivable, operable, understandable, and robust for users with disabilities.
For B2B SaaS, scope depends on what your product does and who it serves. Internal tools used only by employees are sometimes exempt, but any customer-facing interface falls under EAA scope. If your product serves both business users and their end customers, the customer-facing parts are almost certainly in scope.
The enforcement mechanism varies by country but generally involves national market surveillance authorities and, for companies with 10 or more employees, a requirement to publish an accessibility statement and provide a mechanism for users to report barriers. Non-compliance can result in fines, and enterprise procurement teams are increasingly including EAA compliance as a vendor requirement.
The Triage Framework: Four Severity Levels
Before you start fixing things at random, you need a triage map. Accessibility issues range from critical blockers that prevent users with disabilities from completing key tasks, to minor enhancements that improve experience without blocking access.
Level 1 - Critical blockers. These prevent a user with a disability from completing a core workflow at all. Examples: a form that cannot be submitted using only a keyboard, an image-only error message with no text alternative, a modal that traps keyboard focus so the user cannot escape, or a video player with no captions on instructional content. Fix these first. They are the issues most likely to generate complaints and to be cited in an audit finding.
Level 2 - Significant barriers. These make core workflows substantially harder but not impossible. Examples: poor colour contrast on primary text and interactive elements, missing form field labels (present visually but absent from the DOM), focus indicators that disappear on interactive elements, or interactive components that announce incorrectly to screen readers. Fix these in the current sprint or the next.
Level 3 - Moderate friction. These create unnecessary difficulty but users with workarounds can still proceed. Examples: inconsistent heading hierarchy, missing skip-navigation links on pages with extensive menus, timeout warnings that do not give adequate advance notice, or tables missing <caption> and header associations. Schedule these within the current quarter.
Level 4 - Enhancements. Best practice improvements that go beyond minimum compliance. These can be backlogged and addressed over the following two quarters.
The triage audit does not require a full WCAG 2.2 AA sweep on day one. It requires enough coverage to find your Level 1 and Level 2 issues so you can prioritise correctly.
What Auditors Actually Test
Understanding what an EAA audit or complaint investigation looks for helps you direct remediation effort where it counts. National market surveillance authorities and accessibility auditors follow structured approaches, typically covering these areas first:
Keyboard accessibility. Open your application and unplug the mouse. Navigate using Tab, Shift-Tab, Enter, Space, and arrow keys. If you reach a point where you cannot proceed, or if you lose track of where focus is, you have a critical issue. Keyboard testing takes less than an hour per core workflow and surfaces the most severe barriers.
Screen reader compatibility. Test with VoiceOver on macOS and iOS, NVDA or JAWS on Windows. Navigate your sign-up flow, the main dashboard, and a common task like submitting a form or filtering a data table. Listen to what is announced. Missing labels, incorrect roles, and broken live regions all show up immediately in screen reader testing.
Colour contrast. Run automated contrast checks using browser devtools or tools like the axe browser extension. Primary text needs a 4.5:1 ratio against its background; large text and icons need 3:1. This is one of the most common failures and one of the easiest to fix if you are using CSS custom properties or a design token system - change the token value and the fix propagates.
Error identification. When form validation fails, does the error message identify the field by name and describe what needs to be corrected? "Invalid input" fails. "Email address must include the @ symbol" passes. Error messages must also be programmatically associated with their field - a <div> with red text next to an <input> is not enough; the input needs aria-describedby pointing to the error element.
Alternative text. All meaningful images need descriptive alt text. Decorative images need alt="". Images of text need the text reproduced in the alt attribute. Charts and infographics need either a text alternative in the surrounding content or a linked long description.
Document title and language. Every page needs a descriptive <title> and a lang attribute on the <html> element. These are basic requirements that automated tools catch immediately.
Automated tools like axe-core, Lighthouse, and WAVE can find roughly 30-40% of WCAG failures reliably. The remainder requires manual and assistive technology testing. Do not rely solely on automated tools to assess your compliance level.
What to Fix This Sprint
Given that you are already past the enforcement deadline, the priority for the current sprint is to close your Level 1 critical blockers. A reasonable sprint scope for a four to six person engineering team:
Run automated axe-core tests across your five most-visited pages and your most critical user workflow (typically sign-up, login, and the primary feature of your product). Document every failure. Export the results.
Prioritise fixes by impact: keyboard traps first, then missing form labels and error associations, then missing alt text on meaningful images, then contrast failures on primary interactive elements.
If your React components use a UI library (Radix, Headless UI, MUI, Chakra), check the library's own accessibility changelog. Many common accessibility issues in React applications come from incorrect usage of component libraries rather than from custom code. Radix UI in particular has well-documented ARIA patterns; if you are not using the recommended composition approach, you may be overriding the accessible defaults.
For Next.js applications specifically: ensure that client-side route transitions announce the new page title to screen readers. The App Router does not do this automatically in all configurations. A simple approach is a visually hidden live region that updates on navigation, populated by the page title.
The Accessibility Statement
EU member states require in-scope organisations to publish an accessibility statement. The statement serves two purposes: it discloses known compliance gaps honestly, and it provides a feedback mechanism for users encountering barriers.
A defensible accessibility statement includes:
The compliance status - either fully compliant, partially compliant, or non-compliant - with the relevant standard (WCAG 2.1 AA). Do not claim full compliance unless you have evidence from a complete audit. Partially compliant with a list of known exceptions is far better legally than a false claim of full compliance that a user can immediately disprove.
A list of known non-conformities. This is not an admission of guilt; it is a demonstration that you have assessed your product and are aware of the gaps. An auditor finding non-conformities that you failed to list is worse than listing them yourself.
The date the statement was last reviewed. Regulators look for evidence that the statement is maintained, not just published once. Review it quarterly.
A feedback mechanism - typically an email address or form - where users can report accessibility barriers and request alternative formats. You must respond to such requests within a reasonable timeframe (most national laws specify a period in the range of two weeks).
Contact details for the relevant national enforcement body, so users know where to escalate if their feedback is not addressed.
Publish the statement at a consistent URL, typically /accessibility or /accessibility-statement, and link to it from the footer of every page.
Integrating Accessibility Into the Development Workflow
Remediation fixes a snapshot in time. Without process changes, new accessibility issues will accumulate alongside new features. The minimum sustainable process for a small to mid-size team:
Add axe-core to your CI pipeline. The @axe-core/playwright integration runs automated checks on every PR and fails the build on Level 1 violations. This does not replace manual testing but it catches regressions automatically.
Add an accessibility component to your design review checklist. Before any new UI component reaches development, ask: does the design show focus states? Are error states announced or only colour-coded? Are interactive targets at least 24x24 CSS pixels (WCAG 2.2 requirement)?
Designate an accessibility owner. Not a full-time role, but someone who takes responsibility for tracking the remediation backlog, running periodic manual tests, and reviewing the accessibility statement quarterly. This person should have authority to flag accessibility issues as blockers.
If you are working on a custom software development engagement or undertaking a legacy code modernisation, building accessibility in from the component level is significantly cheaper than retrofitting it later. The same principle applies to your own product.
Getting External Help
For teams that need a structured audit rather than self-assessment, an external accessibility audit by a specialist covers both automated and manual testing across assistive technologies, produces a prioritised remediation report, and can provide a supporting statement useful in procurement and regulatory contexts.
If you are preparing for enterprise sales where procurement questionnaires include EAA compliance questions, having an audit report from a named specialist is more persuasive than a self-assessment. Wolf-Tech can assist with the technical remediation side of accessibility improvements in React and Next.js codebases, or review the accessibility implications of architectural decisions in a web application development context. For audit methodology and the full WCAG 2.2 test suite, partnering with a dedicated accessibility specialist alongside the engineering work gives you the most complete coverage.
The enforcement deadline has passed. The organisations most at risk right now are those that have done nothing and cannot show a plan. A triage-first remediation approach, a published accessibility statement that is honest about known gaps, and a CI process that prevents regression - these three things, delivered within the next two sprints, put you in a substantially stronger position than doing nothing while waiting for a perfect implementation.
Questions on the engineering implementation side can go to hello@wolf-tech.io. The goal is progress you can demonstrate, not perfection you cannot reach.