Accessibility Is a Sales Problem Before It Is an Engineering One

For most B2B SaaS companies, accessibility does not arrive as a moral question or a legal one. It arrives as a document request, from a procurement team, late in a deal, with revenue attached.

That timing is the whole problem. The engineering work is ordinary. The engineering work done under a deadline set by somebody else's legal department is not.

Here's what this guide covers:

1. The four ways the request reaches you
2. Why it stalls deals rather than killing them
3. What you can fix in a week, and what takes a quarter
4. What to tell the buyer while you fix it

How it actually shows up

A VPAT request. The most common form. Procurement asks for a VPAT or an Accessibility Conformance Report, usually as one line in a longer vendor packet.

A line in a security questionnaire. Often phrased as "WCAG 2.1 AA conformance", sometimes with no version at all.

An RFP requirement. Public sector and universities frequently make it a scored criterion rather than a yes-or-no.

A European customer citing the EAA. The European Accessibility Act applies from June 2025, and covered organisations discharge part of their duty by requiring conformance from vendors.

Notice what none of these are: a user complaint. By the time this reaches you it is a purchasing condition, and the person asking has no interest in a philosophical conversation about it.

Why it stalls deals rather than killing them

Buyers are not expecting perfection. They are assessing something narrower: do you know what your own product does, and is there a plan?

The buyer usually cannot proceed without the document. Their own obligation depends on the software they run, so approving a vendor with no conformance information creates a problem for them.

But they are not expecting perfection. A bank's accessibility team has reviewed hundreds of these and has never seen a flawless product. What they are assessing is narrower and more answerable: do you know what your own product does, and is there a plan?

This is why the instinct to claim full conformance backfires so reliably. A report marked "supports" on every row does not read as excellent. It reads as untested, and it invites the reviewer to go looking — which they do, and which they are good at.

What you can do in a week

Tab through your product. No tools, no budget. Start at the sign-up and move through the primary workflow using only the keyboard. Watch for three things: anywhere you cannot reach, anywhere you cannot see where you are, and anywhere focus goes in and will not come out.

That last one is a keyboard trap, and it is the defect that blocks somebody completely. Custom modals, dropdowns and clickable table rows are where they live. Rows built as divs with click handlers are the single most common cause, and they pass every automated check — valid markup, adequate contrast, alt text present, and unusable without a mouse.

Run a scanner such as axe or WAVE on the main screens. It will find contrast failures and missing labels quickly. Treat the output as the floor rather than the result; automated tools reach a minority of the success criteria.

Establish which standard and version the obligation actually names. This matters more than teams expect. EN 301 549, the standard used for the European Accessibility Act, has a new version: v4.1.1, published by ETSI in September 2026, moves to WCAG 2.2. Until it is cited in the EU Official Journal, the legal reference is still v3.2.1, based on WCAG 2.1, per the EU AccessibleEU centre. Building to the newer version because it is newer is a choice, not a requirement, and paying for it while believing it was mandatory is a budgeting error.

Write down what you find, including what you did not test. Scope stated plainly is a credibility signal.

What takes a quarter

Restructuring components that were never built to be operable. Retrofitting focus management into a custom table. Fixing a design system whose colour tokens fail contrast in half their combinations — see color system. Adding the states nobody designed: error announcements in an assertive live region, loading states that say something, empty states that are not just blank.

None of it is hard. All of it is slower than the deal cycle, which is the argument for starting before the request arrives rather than after.

Triage, in order

1. Keyboard operability on the primary workflow. Blocks people entirely, checked first by reviewers, invisible to scanners, and more expensive every month as the component spreads.

2. Visible focus. Frequently removed deliberately because it looked untidy. Restoring it is a CSS change.

3. Contrast. Quick, mechanical, and measured against the background the element actually sits on rather than against white.

4. Labels and names. A scanner confirms a label exists; only a person confirms it says something useful. See form design.

5. Announcements. Errors and state changes that happen silently.

Sort by who is blocked, never by what is easy. A list sorted by effort fixes the alt text and leaves the keyboard trap.

What to tell the buyer

Say what you tested, what passes, what partially passes, what fails, and when the failures will be fixed. Attach dates you can actually hold.

If the deal is waiting and the testing is not done, say that and give a date. Buyers are used to hearing it. They are much less used to receiving a report that falls apart when their team reads it against the product, and the second outcome damages more than the delay would have.

The report is a self-declaration — that is what voluntary means in the name — so buyers who know the format ask who did the testing. A report backed by an independent accessibility audit carries weight a self-assessment does not, and saying so in the document is an advantage rather than an admission.

The version worth building instead

Everything above describes the reactive path, which is the one most teams take and the expensive one.

The alternative is unglamorous: keyboard operability and contrast treated as build requirements rather than as a phase, the same way nobody schedules a sprint for "make the buttons clickable". At that point the audit confirms rather than discovers, the report writes itself, and the procurement request stops being an event.

That is also, separately, inclusive design — designing for the range of people who will use the product rather than for the ideal case. It is worth doing for its own reasons. But the argument that moves a roadmap is usually the one with a contract attached, and there is no reason not to use it.

If you want to know where your product stands before a customer tells you, our UX audit covers this, and the keyboard pass above will already have told you most of the answer for free.