Web applications · procurement questionnaires · weekly releases
SaaS accessibility: the question that arrives with the security review.
For most software vendors accessibility does not arrive as a law. It arrives as question 47 in a procurement pack, three weeks before the contract is due to be signed, phrased in terms nobody in the sales team recognises. This page explains what is actually being asked, which parts of a SaaS product get tested, how weekly releases change the maintenance problem, and what a credible answer looks like when the buyer is a public body or a large enterprise.
Test credentials stay with the tester. Nothing is installed in your product.
Which parts of a SaaS product are in scope
A web application is not a set of pages to sample: it is a set of tasks a user repeats every day, and the scope follows the tasks.
| Area | Why it is tested | Typical finding |
|---|---|---|
| Sign-up and login | First contact, and often the first barrier | Authentication puzzles with no accessible alternative |
| Main application | Where the service is delivered | Custom components without names, roles or states |
| Data tables and grids | The core of most business software | Sorting and filtering that announce nothing |
| Modals and drawers | Everywhere in modern interfaces | Focus not moved in, not returned out |
| Forms and settings | Long, validated, error-prone | Errors shown visually and never announced |
| Notifications | Asynchronous by nature | Toasts that disappear before they are read |
| Billing | Contractual and often third-party | Payment iframe with its own focus behaviour |
| Help centre | Covered by the European standard | Search results and article navigation unreachable |
The pattern is consistent: it is not the pages that fail, it is the components. Which is good news, because a design system fixed once propagates everywhere.
The design system is the leverage
In a product built from a component library, most findings trace back to a dozen components: the button, the input, the select, the date picker, the modal, the tab set, the table, the toast, the menu, the tooltip, the file upload and the combo box. Fix those twelve properly and the majority of the report disappears across every screen at once.
This is why the findings report for a software product is organised by component rather than by page. A list of ninety page-level issues is demoralising and largely redundant; a list of twelve components with the specific defect in each is a sprint.
It is also why accessibility work in SaaS tends to be cheapest in the first year and cheaper still afterwards: the fixes are structural, they live in shared code, and new screens inherit them automatically.
Weekly releases and the regression problem
This is the difference between software and every other kind of website, and it is the reason a one-off audit ages badly here.
A shop changes when somebody installs an app. A SaaS product changes every week, sometimes every day, and every deploy can reintroduce a defect that was fixed months ago. An annual audit in that environment describes a version of the product that no longer exists by the time the report is read.
Two things help. The first is the monthly re-test included in the plan: each run is compared with the previous one, so a regression surfaces within weeks rather than at the next procurement cycle. The second is internal: the components fixed during remediation should carry tests, so the defect cannot return silently. We tell you which ones are worth guarding, based on what actually broke.
What the buyer is really checking
Procurement teams are not auditing your code. They are deciding whether you are a risk they can accept, and they read four signals. Whether the document is dated and matches the version they are buying. Whether an external party tested it, or whether it is a self-assessment with confident wording. Whether the gaps are named, because a vendor who names gaps is a vendor who knows their product. And whether there is a plan with dates rather than an aspiration.
A report that gets all four right closes the question in one exchange. A report that claims perfection invites a demo account and a five-minute test, and the person doing that test knows exactly where to look.
What we deliver to a software vendor
An audit of the application with your test credentials, the marketing site, the sign-up and billing flows and the help centre. A findings report organised by component and by criterion, ordered by what a user cannot do. The public accessibility statement if you publish one, signed by Europe Services SE for the European Union, with a verification code anyone can check. Monthly re-testing with regression comparison, a hosted feedback channel, and five years of records.
For the supplier report itself, the evidence transfers directly into whichever template your buyer uses, as explained on the VPAT comparison page, and the clause mapping buyers cite is set out on the EN 301 549 page.
A realistic first year
Nothing below assumes a dedicated accessibility team or a pause in the roadmap. It assumes an ordinary product team with an ordinary backlog.
Month one: audit with credentials, findings by component, statement published listing what is open. Months two and three: the twelve components are corrected in normal sprints, which for most teams is a handful of days of work spread across two releases, and each fix removes findings from every screen at once. Month four onwards: monthly regression checks, a short email when something moves, and a report that stays current without anyone scheduling a project.
By the next procurement cycle the answer to question 47 is a dated external report, a public statement, and a list of gaps that is shorter than it was. That is a materially better position than the one most vendors are in, and it was achieved inside the normal release rhythm rather than beside it.
The twelve components, and what usually goes wrong in each
This list is the practical core of a SaaS audit. If your design system handles these twelve correctly, most of the report is already written in your favour.
Button. Icon-only buttons with no accessible name, and clickable div elements that a keyboard cannot reach. The most common single defect in business software.
Input and label. Placeholder text used as the label, so the field is unlabelled as soon as the user types, and the help text below is never associated with the field.
Select and combo box. Custom dropdowns rebuilt for styling reasons, without the keyboard behaviour the native element gave you for free.
Date picker. A calendar grid that cannot be navigated with arrow keys, and no plain text alternative for typing the date directly.
Modal. Focus not moved into the dialog on open, not trapped while it is open, and not returned to the trigger on close. Three separate defects that always appear together.
Tabs. Panels that do not follow the selected tab in the reading order, so the content announced does not match the tab the user chose.
Table. Headers not associated with cells, sorting controls with no state, and row actions hidden until hover.
Toast. Status messages rendered visually with no live region, so success and failure are both silent. In a product where actions are asynchronous this is a serious defect.
Menu. Opens on hover only, or closes as soon as focus moves, which makes it unusable without a pointer.
Tooltip. Content available only on hover, containing information available nowhere else.
File upload. A styled area with the real input hidden and no keyboard route to it.
Search with suggestions. Results updating with no announcement and no way to move into them with the keyboard.
Authentication, and the criterion nobody expects
WCAG 2.2 added a criterion about accessible authentication, and it catches a pattern almost every SaaS product uses somewhere: a login step that requires a cognitive function test with no alternative. Transcribing a distorted image, remembering a code from a previous screen, solving a puzzle, retyping a one-time password that has already been copied to the clipboard. Each was added for security, and each creates a barrier for people with cognitive disabilities, for people using speech input, and often for everyone on a phone.
The fix is rarely to remove the protection. It is to offer a path that does not depend on memory or transcription: support for password managers rather than blocking paste, an email link alternative, or a device-based method. We flag these explicitly because they sit between product and security, and neither team tends to own them until somebody points at the criterion.
Who should receive the findings
In a software company the report has three readers and they need different parts of it. Engineering wants the component list with the defect and the fix. Product wants the severity order, because it decides what goes into which sprint. Sales and legal want the summary and the conformance position, because that is what goes back to the buyer. Sending one undifferentiated document to all three is how reports end up unread in a shared drive; we split it so each group gets what it can act on.
Questions from software teams
Does the EAA apply to a B2B SaaS product?
The Act targets services offered to consumers. Pure B2B software is often outside its scope, but the obligation reaches you through your customers' contracts and through public sector buyers.
So why do B2B vendors need this at all?
Because the accessibility question arrives in the security questionnaire, and an unanswered question blocks the deal.
What if we sell to consumers as well?
Then the Act applies directly to the consumer-facing part, including the marketing site and the sign-up flow.
Which part of the product is tested?
The application itself, the flows a user completes daily, plus sign-up, billing, settings and support.
Do you need a test account?
Yes. The application behind the login is the part that matters, and a public scan never sees it.
What about our marketing site?
Tested too, because it carries sign-up and pricing, and because it is what a buyer opens first.
Do you test our mobile apps?
Native apps follow different guidance and are quoted separately from this plan.
Which standard applies?
WCAG 2.2 level AA for the web product; the European standard adds requirements for documentation and support.
What do buyers ask us for?
A conformance report keyed to the standard, dated, with a stated method and an honest list of gaps.
Can we write it ourselves?
You can, and you own the report. What buyers weigh is whether external testing sits behind it.
How long does testing take?
Five business days from a complete form and working credentials.
What happens when we ship weekly?
The monthly re-test compares runs and flags regressions, which matters more for SaaS than for any other product type.
Does this help our roadmap?
Findings are ordered by what a user cannot do, so they slot into a backlog as ordinary tickets.
What does it cost?
690 € a year for the EU, 1,290 € for three domains and six languages, 1,990 € including the UK and Canada.
Do you fix our code?
No. We test, document and sign; your engineers implement.
What about our help centre?
In scope. Support content and channels are covered by the European standard, and a barrier plus an unusable help centre is a complaint.
Can we publish the statement?
Yes, and we recommend it: a public, honest statement answers half the questionnaire before it is sent.
Where do we start?
Free scan of the marketing site, then the audit with credentials for the product.