How procurement teams actually evaluate accessibility vendors

Last month I was on a call with a procurement officer at a mid-sized fintech who wanted to know which lines of our standard MSA were negotiable before she would let our sales conversation continue. She had a spreadsheet with 47 questions and a column flagged "must answer in writing." We got through nine of them in 40 minutes. Most of the answers were uncomfortable to give, because the honest version was: we are early, here is what we ship today, here is what we do not.

She moved us forward anyway. Not because the answers were what she wanted to hear, but because they were straight, and she could put them in front of her CIO and her general counsel without catching herself short later.

This post is for the people on the buyer side of that conversation — the procurement officers, the legal counsel, the IT directors, the design system leads, and the engineering managers who get handed a directive that says "we need an accessibility solution" and then have to figure out which of the dozen vendors pitching them is worth the line item. It is also for vendor sales teams who keep losing deals at procurement and cannot figure out why. The pattern is the same on both sides of the table, and the failure modes are predictable.

Four buyer roles, four sets of questions

In every accessibility-vendor evaluation I have been part of, there are four roles in the room. They might be four people or one person wearing four hats, but the questions cluster the same way.

Legal and risk cares about what happens when the demand letter lands or the regulator sends a notice. They want to see the vendor's documentation outputs, the contract terms, the data handling, and the off-ramp.

IT and security cares about what the vendor touches inside your environment. What credentials, what scopes, what gets written, where the data lives, what is logged, and whether the vendor has audited controls you can put in your file.

Engineering cares about whether the tool works without making their day worse. Does it plug into what they already run, what is the false-positive rate, does the suggested fix look like something a sane reviewer would merge, and what happens when it is wrong.

Product and design ops cares about coverage and reporting. What is being scanned, what is being missed, and what comes out the other end when an executive asks "where are we on this."

A vendor that cannot answer cleanly across all four columns is going to lose deals at procurement no matter how strong the product demo was. Below are the questions I see most often, with a short note on what a real answer looks like.

Legal and risk

Do you indemnify us against accessibility lawsuits? For almost every accessibility vendor on the market, the honest answer is no. The few that say yes typically cap indemnification at the annual contract value, which means functionally nothing once you have hired counsel and started reviewing complaints. If a vendor pitches indemnification as a feature, ask for the redline. Read it before you read anything else.

For inklu the answer is no. We do not offer lawsuit indemnification, we do not promise WCAG compliance as a contractual outcome, and we do not pretend we can. We help you find and fix violations. We cannot legally represent you, and we should not.

What documentation do you produce for our compliance file? A good answer is a sample report. Ask for an actual export from the vendor's tool — a real one, not a slide. You want to see the violation list, the WCAG criterion mapped to each finding, the affected URLs or component paths, the timestamp of the scan, and ideally evidence of remediation. Bonus points if the report formats cleanly against AODA, ADA Title II, or EAA — those are three different audiences and three different framings of the same underlying axe-core findings.

What happens to our source code or scan results when we leave? If the vendor is hosting your code, ask how long it lives there, who can see it, and what their deletion policy looks like on contract termination. Some tools keep your scan history indefinitely so they can build dashboards. That is a feature for them and a risk for you.

The inklu answer is that source code is purged after each scan. Reports are generated on the fly and not retained server-side. There is no scan history to subpoena because there is no scan history. This is a privacy strength and a real product trade-off — we cannot show you a six-month trend chart because we do not have the data. Some buyers prefer that. Some do not.

Do you sign a DPA? A lot of vendors will. We do not, today. If you require a custom DPA before signing, that is a fair filter and you should screen us out.

IT and security

Do you have SOC 2? This is the question that ends conversations. If a vendor says "Type II in progress" but cannot show you the engagement letter, that is a soft no. If they have a Type I report from this calendar year, that is a real signal. If they have nothing, they should say so cleanly.

inklu has nothing here. We have not started a SOC 2 engagement. If your security team requires SOC 2 as a hard gate, we are not the right fit yet. We will say that out loud rather than dance around it. Other accessibility tooling vendors are further along; check their trust pages directly rather than taking a sales rep's word for it.

What credentials and scopes does the integration require? The most common integration is a GitHub app or a personal access token. Ask which scopes are requested and what each one is used for. The honest description for most accessibility tools is repo scope (which grants full repository access) plus user:email, read:user, and read:org. The repo scope is not minimizable to read-only when the tool needs to open pull requests. Vendors who claim they have engineered around this generally have not — they have just chosen a workflow constraint, like never writing to a default branch, and called the scope question solved. The constraint is real. The scope is still broad.

Where is data hosted, and can we choose region? Most early-stage SaaS runs in one region. If your buyer requires EU residency or in-country hosting, ask the question early. inklu is US East only, no other regions, not even on Enterprise. That rules us out for some buyers in regulated EU contexts. Other vendors with longer roadmaps may have multi-region options — verify on their trust page.

Who at the vendor can see customer data? If the answer is hand-wavy, ask for an access review policy in writing.

Engineering

What is the false-positive rate, and what do you do about it? Every automated accessibility tool has false positives. Anyone who tells you their rate is zero is either lying or testing only the easy criteria. WebAIM's annual analyses (worth reading directly at webaim.org for current methodology) consistently find that automated scans surface a meaningful subset of violations but miss the majority of subjective ones, and any tool will throw flags that are technically correct but pragmatically wrong for your specific UI. A good vendor talks openly about this and shows you how to ignore, override, or scope rules.

What is the integration with our existing toolchain? If your team lives in GitHub, the bar is GitHub Actions or a GitHub app. If you live in GitLab or CircleCI, ask explicitly — many tools that claim CI/CD support actually mean GitHub-only and will roadmap the rest. inklu is GitHub Actions today; GitLab and CircleCI are roadmap. Be skeptical of vendors who list every CI system as supported on a marketing page; ask for documentation links and a live demo against your actual platform.

What do the suggested fixes look like? This one is easy: ask the vendor to run their tool against a public repo with known accessibility issues and show you the resulting pull requests. Then have an engineer on your side look at the diffs without sales context. Would you merge them? Would you ask for changes? Would you close them? The answer to that question matters more than any feature checklist.

What languages and frameworks? Most code-fix vendors support a handful — usually HTML, CSS, and one or two JavaScript framework dialects. inklu supports HTML, CSS, JSX (including TSX), and SCSS. Angular is on the roadmap. Vue, Svelte, server-rendered template languages — not supported. If your stack is not on the list, do not let a sales rep tell you "we can probably handle it." Ask for a sample fix on a snippet you provide.

Product and design ops

What is the unit of measurement? Some vendors charge per page, some per scan, some per fix, some per seat. inklu uses tokens — a web scan is 2 tokens, a repo scan is 8, an auto-fix pull request is 1. The plans run from 40 tokens at $29/mo on Starter up to 2,000+ on Enterprise. The full breakdown is on the pricing page. The right pricing model for you depends on whether your audit cadence is steady (page-based works) or bursty (token-based works better, because you can spend down a budget how you want).

What does the report look like when the CEO asks? Ask for an executive summary export. If the only export is a CSV of raw violations, that is a feature gap.

Coverage limits? No automated tool catches everything. The Deque "State of Accessibility" research (publicly available, worth reading) is a useful baseline for what automation can and cannot detect. Manual testing still matters for cognitive load, navigation logic, and content clarity. A vendor that pretends otherwise is selling you a story.

How to run the evaluation in a week, not a quarter

If you are the person responsible for picking a vendor, here is the lightest-weight evaluation that actually works.

Pick three candidates. One is the incumbent or the obvious enterprise pick. One is a younger source-code-fix tool. One is whatever your engineering team has been talking about. For inklu, our comparisons — including accessiBe, axe DevTools, and Siteimprove — exist precisely so a buyer can do this triage without spending two weeks on demo calls.

Send each of them the same five questions in writing, all from this post: indemnification, SOC 2 status, what scopes the integration requests, what the suggested fix looks like (with a sample repo), and what the report looks like (with a sample export). Give them a week to respond. The ones who respond cleanly and quickly are the ones to demo.

Run the demo against your actual code, not their canned demo site. If they push back on this, that is a signal.

Have one engineer, one security or IT person, and one PM in the demo. Each one is responsible for asking the questions in their column above. Take notes. Compare.

You will know within an hour which vendor is the right fit. The hard part is getting through the first filter — and the first filter is whether they can answer straight.

A closing note

Procurement is going to ask these questions whether vendors prepare for them or not. The ones who answer honestly win the deals worth winning. The ones who dodge get filtered at legal review and never know why. We have lost deals over the SOC 2 answer, the indemnification answer, and the region answer. Each one was the right loss.

If you want to see how inklu answers these questions in production — with the actual scan output, the actual pull request, the actual report — book a demo at inklu.io or email hello@inklu.io. The FAQ covers the most common ones in writing first.