Accessibility Certified – Home
Free check Menu

Industry · SaaS and software

Pass the procurement check, keep every user on board

Buyers increasingly ask how accessible your product is before they sign. We test your web app against WCAG 2.2 AA, including the logged-in product itself, and give you a report and certificate your sales team can point to.

Free checkRequest an audit
Three people from a product team gather round a laptop with a bar chart, coffee cups on the table between them.

B2B or B2C: why it matters

Consumer software: if consumers sign up and pay through your website or app, that part can count as an e-commerce service under the European Accessibility Act. E-books and the software dedicated to them are named separately. Micro-enterprises providing services are exempt.

Business software: offers aimed only at businesses are outside the EAA. But your customers may be covered. A shop system, booking tool or banking component you supply becomes part of their service to consumers, and they will ask you about it.

Public sector buyers: under Directive 2014/24/EU, technical specifications for anything used by people must take accessibility into account, except in duly justified cases. The usual reference is EN 301 549. Our guide to accessibility in tenders explains how buyers phrase it.

Two questions, one answer

Does the EAA apply to you?

Your industry is already selected. Answer two questions and the EAA check shows an assessment, the reasons and next steps. You can change every answer there.

Who are your customers?
How big is your company?

A first orientation, not legal advice. Nothing is stored.

What we look at in a web app

Custom components

Comboboxes, date pickers, data grids and tree views built from divs. They need the right roles, states and keyboard behaviour.

Focus management

Where does the focus go when a dialog opens, a panel closes or the route changes? Lost focus is one of the most common web-app failures.

Live updates

Autosave notices, toasts, validation and progress must reach screen reader users without stealing the focus.

Dense interfaces

Small icon buttons, low-contrast borders on inputs and controls that look disabled when they are not.

Drag and drop

Boards, sorting and resizing need a single-pointer or keyboard alternative.

Sign-in

SSO, multi-factor codes and password rules, tested so that nobody is shut out at the door.

Criteria that matter most in web apps

  • 4.1.2Name, Role, Value

    Every custom control must tell assistive technology what it is, what it is called and what state it is in.

  • 2.4.3Focus Order

    After opening a dialog or changing views, the focus must move in a logical order and return to a sensible place.

  • 2.4.11Focus Not Obscured (Minimum)

    Sticky toolbars, cookie banners and chat bubbles must not completely cover the element that has keyboard focus.

  • 2.5.7Dragging Movements

    Anything that works by dragging needs a way to do the same with single clicks or taps.

  • 2.5.8Target Size (Minimum)

    Targets need to be at least 24 by 24 CSS pixels, or have enough space around them. Icon toolbars often fail.

  • 4.1.3Status Messages

    Messages such as “Saved” or “3 errors” must be announced as status messages.

How we test a SaaS product

  1. Fix the scope

    Marketing site, sign-up, and the product journeys your customers use most. We record the app version; it appears on the certificate.

  2. Test access

    You give us a test account in a test or staging environment. The scanner covers public pages; it never logs in.

  3. Human review

    The reviewer tests the logged-in journeys with keyboard and screen reader and decides all 55 criteria.

  4. Release rhythm

    Monitoring watches the public pages after launch. For major releases of the logged-in product, plan a new audit.

EN 301 549 and your product

EN 301 549 is the European standard for accessible ICT. Version 3.2.1 is the harmonised reference for public sector websites and apps; its web clause is based on WCAG 2.1 AA. Version 4.1.1, published on 2 September 2026, aligns its web, document and software clauses with WCAG 2.2.

The standard covers more than web content, for example software and documentation. Our audit tests WCAG 2.2 AA for web content; clauses beyond WCAG, such as those for software, documentation and support, are not part of it. The certificate names the standard and version, so buyers can see exactly what was tested.

Frequently asked questions

We only sell to businesses. Why bother?

Because your buyers ask. Public bodies have to consider accessibility in tenders, and companies covered by the EAA need the tools they use to build consumer services to be accessible. People with disabilities also work in your customers’ teams.

Can our sales team use the certificate in tenders?

Yes. It has a public verification page with scope, standard, test date and expiry. Some buyers ask for a conformance report in a specific format; we do not currently fill in such forms, but our report contains every decision and its evidence that you need for them. The certificate does not state that you meet any law.

We release every two weeks. Is a snapshot useful?

It proves the state of a named version, which is what buyers ask for. Between audits, monitoring catches regressions on public pages. Fixing the shared components found in the audit protects later releases too.

Can you plug into our CI pipeline?

Not at the moment, and we give no date until it exists. Until then, see our developer page for checks you can run yourself.

Related