EU Accessibility Act And EN 301 549
The EU Accessibility Act (Directive (EU) 2019/882) sets accessibility requirements for certain products and services, including many digital services sold to consumers and businesses. For SaaS, the practical question becomes which user-facing features fall under the directive and which accessibility standards are used to demonstrate compliance. EN 301 549 is the harmonised European standard that many organizations use as the technical reference for accessibility requirements across ICT products and services.
A gap audit compares what your SaaS currently does against the EN 301 549 requirements that apply to your product scope. A useful audit does not treat EN 301 549 as a single checklist. It breaks the standard into testable claims tied to user journeys such as signing in, searching, creating content, submitting forms, and receiving notifications. For example, if your app supports keyboard-only navigation, the audit should test focus order, visible focus styling, and whether interactive controls expose correct semantics to assistive technologies.
In practice, the audit also needs to account for dependencies outside your code. Your SaaS may rely on a third-party identity provider, a payment flow embedded in an iframe, or a document viewer. Those components can shift where the accessibility work happens, and the audit should record which vendor owns which part of the experience. I have seen teams treat “we use a compliant vendor widget” as the end of the story, then discover the widget is compliant only under certain configuration flags, which, frankly, most people skip.
Common Pain Points In Audits
Teams often misread EN 301 549 by focusing on a few visible UI issues and skipping the underlying mechanisms. Screen reader support depends on semantic markup, accessible names, and correct state changes, not just labels on buttons. Keyboard support depends on focus management, not just tab order. Color contrast depends on the actual rendered colors in each theme, not the design system tokens alone.
Another frequent gap comes from content and workflow, not controls. EN 301 549 covers things like error identification, instructions, and the way information is presented when users change settings. If your form validation shows errors only after a submit click, users who rely on assistive technology may not receive timely feedback. If your app uses toast notifications without a live region, the message may never reach screen reader users.
Audits also fail when they ignore the “supporting technologies” layer. A modern SaaS UI might use ARIA, custom components, virtualized lists, and client-side routing. Virtualized lists can break screen reader navigation if off-screen items are not handled correctly. Client-side routing can break focus restoration when users move between pages. Even the version of a component library matters; I once reviewed a report where the audit assumed a fix landed in “the next release,” but the product was still on React 16.14 and the issue persisted.
Finally, teams sometimes confuse internal accessibility with external accessibility. Internal QA might pass with a single browser and a single screen reader, then fail for other combinations. EN 301 549 expects behavior that works across assistive technologies and user agents, so the audit should include a small but deliberate matrix rather than a single “it works on my machine” check.
Solutions And Advice For A Gap Audit
Map Scope To User Journeys
Start by listing the SaaS features that users must complete to achieve their goals: account creation, authentication, dashboard navigation, search, data entry, file upload, document viewing, and export. For each journey, record the UI components involved and the content types used, such as tables, charts, and downloadable files. Then map each journey to the EN 301 549 requirement areas you will test, such as text alternatives, keyboard access, focus management, and error identification.
Use a simple evidence plan per journey: screenshots for visual issues, screen reader test notes, and logs of keyboard navigation steps. If your app has multiple themes, include at least one high-contrast theme in the scope, because contrast failures often appear only in alternate styling. A realistic outcome for a first pass is a prioritized list of 20 to 60 testable items, not a single pass/fail score.
Run Targeted Tests With A Matrix
Build a test matrix that covers the most likely assistive technology paths for your user base. A practical baseline often includes one major browser with a screen reader and keyboard-only navigation, plus at least one additional browser for cross-compatibility. Keep the matrix small enough to execute, but specific enough to produce evidence. For example, test keyboard focus order and activation on the same pages where you test screen reader announcements, because fixes in one area can regress the other.
For component-heavy apps, test custom controls directly. Verify accessible names for inputs, correct role and state exposure for toggles, and live region behavior for dynamic updates. If you use a virtualized table or list, test how screen readers move through rows and whether the current row is announced when scrolling. A mild frustration many teams hit: automated tools flag missing labels, but they do not catch focus traps or incorrect announcement timing, so manual checks still dominate.
Track results with a versioned audit log. If you run the audit on 2026-03-14 and your team changes the UI in the next sprint, you need a record of what was tested. Tools like axe DevTools can speed up discovery, but treat them as a triage signal rather than proof of compliance.
Document Remediation And Ownership
For each gap, write a remediation ticket that names the affected user journey, the EN 301 549 requirement area, the current behavior, and the expected behavior after the fix. Include acceptance criteria that can be tested, such as “keyboard focus moves to the first invalid field after submit” or “error messages are announced by screen readers without requiring focus to change.”
Assign ownership across teams. If the gap is in a third-party identity flow, the ticket should go to the vendor management process, not only the front-end team. If the gap is in your document viewer, the ticket should include which file types are affected, such as PDF, DOCX, or HTML exports. A realistic outcome for remediation planning is a breakdown like 30% UI semantics, 25% keyboard and focus, 20% content and instructions, and the rest in dynamic updates and third-party dependencies, though your distribution will vary.
When you close a ticket, record the evidence again. A common audit failure is closing based on a developer’s local test, then discovering a regression in a different browser or theme. Re-test the same journey steps and update the audit log.
Use A Repeatable Audit Cadence
Accessibility gaps reappear when new features ship. Set a cadence that matches your release cycle, such as a pre-release audit for major UI changes and a smaller regression sweep for minor changes. Keep a “known issues” list with severity and workaround notes, because users may need temporary alternatives.
For SaaS, include onboarding and account management flows in the cadence. These areas often change due to security updates, password policies, or identity provider upgrades. I have seen accessibility regressions after an SSO configuration change, where the login page focus order changed and the screen reader started reading hidden elements.
Maintain a living accessibility statement draft that matches your evidence. Even if you do not publish it yet, aligning internal documentation with what you can test reduces compliance churn later.
Case Examples For SaaS Teams
Example 1: Form Errors And Live Updates
A SaaS HR tool had a multi-step form for employee onboarding. The team used client-side validation that displayed errors as red text next to fields, but it did not move focus to the first invalid field after submit. Screen reader users reported that they had to search manually for errors, and keyboard-only users sometimes stayed on the last field they edited.
The gap audit mapped the issue to error identification and instructions. The remediation added an error summary region with a live announcement and moved focus to the first invalid input after submit. The team also verified that error messages had programmatic associations to the relevant fields. After the fix, the audit log recorded keyboard steps and screen reader output for the same form pages.
Example 2: Virtualized Tables And Navigation
A project management SaaS used a virtualized data grid to render thousands of tasks. The grid supported keyboard navigation, but screen reader users could not reliably move between rows because off-screen rows were not exposed in the accessibility tree. When users scrolled, announcements lagged behind the visual row.
The audit treated the grid as a supporting technology dependency. The team tested the grid with a screen reader and confirmed that row changes were not announced consistently. The remediation adjusted the virtualization strategy so that the current viewport rows were exposed with correct semantics, and it added an accessible status update when the active row changed. The team re-ran the same navigation script on the same browser and screen reader combination to confirm the timing behavior.
EN 301 549 Gap Audit Checklist
This checklist helps you decide what to test first and how to record evidence. It is not a substitute for legal advice or a full standard interpretation.
| Area To Check | What To Look For | Evidence To Capture | Typical Fix Type |
|---|---|---|---|
| Keyboard Access | Focus order, visible focus, no traps, activation works | Keyboard step log and focus screenshots | Focus management and control semantics |
| Text Alternatives | Meaningful labels for icons, images, and controls | Screen reader output notes | ARIA labels and content updates |
| Forms And Errors | Error identification, association, and instructions | Before/after behavior recordings | Error summary and focus to first invalid |
| Dynamic Updates | Live regions, status announcements, no silent changes | Live region test notes | ARIA live and event timing fixes |
| Tables And Grids | Header associations, navigation, virtualization behavior | Row/column navigation script results | Semantic grid roles and virtualization tuning |
Step-by-step approach: pick one critical journey, run keyboard and screen reader tests on the same pages, record evidence, then prioritize fixes by user impact and regression risk. If you have limited time, start with journeys that include forms, tables, and dynamic updates, because these areas tend to produce the most audit findings.
Common Mistakes That Undermine Trust
One mistake is treating automated accessibility scanning as compliance evidence. Tools can detect missing attributes and some contrast issues, but they cannot confirm correct focus order, timing of announcements, or whether instructions are understandable in context. A report that lists only tool findings without manual test notes reads like a checklist, not an audit.
Another mistake is copying requirement text into tickets without describing the current behavior. If a ticket says “fix keyboard accessibility” without stating where the focus trap occurs, the team cannot verify closure. EN 301 549 gap audits work best when each finding includes a reproducible scenario, such as “press Tab from the search field, focus skips the results filter.”
Teams also over-rely on design system documentation. A design system can define tokens, but the rendered output depends on component usage, theming, and runtime state. If you use a component library, record the exact version and the configuration. I have seen audit gaps appear after a theme override changed contrast, even though the base theme passed earlier checks.
Finally, avoid vague claims in compliance documentation. If you state that a third-party widget is “accessible,” record the test scope, the widget version, and the configuration used. If you cannot test it, document the limitation and the plan to obtain evidence from the vendor.
FAQ
Does EN 301 549 Apply To All SaaS Features?
EN 301 549 is used as a technical reference for accessibility requirements, but the EU Accessibility Act applies to specific categories of products and services and to specific user-facing functions within scope. A gap audit should start with your product scope and map only the relevant user journeys to the standard.
What Evidence Counts In A Gap Audit?
Evidence usually includes reproducible test steps, screenshots for visual issues, screen reader notes for semantics and announcements, and keyboard navigation logs. Automated scans can support triage, but manual checks are needed for focus behavior and dynamic updates.
How Should We Test Virtualized Tables?
Test how screen reader users move between rows and whether the active row is announced when scrolling. Confirm that off-screen content does not break navigation and that headers and cell associations remain correct during virtualization.
Can We Rely On Third-Party Widgets For Compliance?
You can reduce work when a vendor provides accessibility evidence, but you still need to test the widget in your actual configuration and user journeys. If you cannot test it, document the limitation and track a plan to obtain verifiable evidence.
How Often Should We Re-Audit After Fixes?
Re-audit on a cadence tied to releases that change UI, content rendering, or identity and notification flows. A practical approach is a regression sweep before major releases and a smaller check for minor changes that touch accessible components.
Author's Insight
EN 301 549 gap audits succeed when they connect requirements to user journeys and record evidence that another team can reproduce. The standard covers more than visible contrast and labels, so audits need manual testing for focus order, error handling, and dynamic announcements. For SaaS, supporting technologies such as identity providers, document viewers, and virtualized grids often create the largest compliance risk, because they change behavior at runtime. A careful audit log with dates and tested versions helps teams avoid “we fixed it” claims that cannot be verified later.
Key Takeaways
- Map EN 301 549 to concrete SaaS journeys, not to a generic list of UI components.
- Use a small but specific test matrix that covers keyboard behavior and screen reader announcements.
- Document each finding with reproducible steps and capture evidence after remediation.
- Treat third-party dependencies and virtualized UI as first-class audit targets.
- Plan a repeatable audit cadence tied to releases that affect accessible behavior.
