Proof, Not Promises: A UK Procurement Test for SaaS Accessibility Claims

Accessibility statements have become a familiar artefact in SaaS procurement. They are usually published on a vendor's website, written in broad terms and presented as evidence that the product has been designed for disabled users. For UK buyers, that is not enough. A statement may be accurate, but it is still a claim. It does not show which user journeys were tested, which standard was applied, which defects remain open or whether the vendor has the ability to fix them within a reasonable period.

The distinction matters because accessibility is moving from a specialist concern to a mainstream procurement condition. Public-sector bodies have obligations under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, with WCAG 2.2 level AA as the reference point for web content. Private-sector organisations face their own pressures under the Equality Act 2010, particularly where a poorly accessible service creates a barrier to employment, customer access or reasonable adjustments. Even where no formal duty applies, accessibility is increasingly part of supplier assurance, cyber and ESG questionnaires, and customer contracts.

The statement is a starting point, not a test result

A credible accessibility statement should identify the standard being followed, the scope of the product covered, the date of the last review and a contact route for users who encounter barriers. It should also say what is not yet accessible and when remediation is expected. Those are useful disclosures. They are not proof that the product meets WCAG 2.2 in the workflows a buyer will actually use.

Many statements fail at exactly this point. Some are generic templates copied from a marketing page. Some refer to WCAG 2.1, which is no longer the current benchmark for many UK assessments. Some cover a company website but not the SaaS application itself, or cover the application but not the mobile app, admin console, reporting module or embedded third-party components. Others are undated, list no test method and offer no evidence that assistive technology was used.

The procurement question is therefore not 'do you have an accessibility statement?' It is 'what evidence can you provide that the user journeys we are buying have been tested against the standard we require, and what happens if they fail?'

What to request beyond the statement

A serious supplier should be able to provide an accessibility conformance report, often based on a VPAT or a similar template, aligned to WCAG 2.2 level AA and, where relevant, EN 301 549. The report should be scoped to the product edition and modules being purchased. A platform-wide claim is of limited value if the buyer is purchasing a specific workflow, region or integration set.

Buyers should ask for the date of the last assessment, the name of the assessor or audit firm, the method used and the extent of manual testing. Automated scans catch some issues, but they do not replace keyboard testing, screen-reader testing, zoom and reflow checks, contrast checks or testing with users who rely on assistive technology. A report that relies solely on automated tooling should be treated as incomplete.

The defect log is equally important. Ask for known accessibility issues, their severity, the affected user journeys and the vendor's remediation timetable. A supplier that claims full conformance without listing a single known limitation is either exceptionally mature or insufficiently tested. In most enterprise SaaS, the second explanation is more common.

How to spot untested claims

There are practical warning signs. A statement that says the product is 'fully compliant' without qualification is difficult to reconcile with the complexity of most SaaS platforms. A report that is more than two years old may not reflect subsequent releases, redesigns or third-party component changes. A statement that offers no feedback mechanism, or no enforcement or escalation route, is unlikely to support a user who encounters a barrier after go-live.

Buyers should also check for a mismatch between the public statement and the contractual documentation. If the statement says WCAG 2.2 AA but the contract refers only to 'accessibility best practice', the buyer has little leverage. If the vendor's roadmap promises remediation but the contract contains no milestone or remedy, the promise is commercial courtesy rather than an obligation.

A short practical test is to ask the vendor to demonstrate two or three critical journeys using a keyboard only and with a screen reader. This need not be a full audit. It is a reasonable evidence request during a competitive tender or renewal. Vendors that have tested their product properly can usually support it. Vendors that have not will often redirect the conversation to their statement.

Build accessibility into the procurement process

Accessibility requirements should appear in the requirements catalogue, not in a separate policy annex that nobody scores. Define the standard, the scope and the evidence required. Include accessibility scenarios in the demo script. Ask for test accounts or a sandbox so that the buyer's own specialists can check key workflows before contract award.

During implementation, clarify who is responsible for accessibility in configured content, templates, forms and integrations. A compliant platform can still produce an inaccessible service if the buyer populates it poorly or embeds third-party tools that have not been assessed. Training and content guidance are therefore part of the deliverable, not an afterthought.

Contractual remedies that carry weight

If accessibility is a material requirement, the contract should say so. Define measurable acceptance criteria, require a remediation plan for known defects and set dates for closure. Consider service credits or fee withholding for material non-conformance that persists beyond an agreed period. For higher-risk purchases, include audit or evidence rights and a termination route for sustained failure to meet the agreed standard.

The contract should also require notification when a release introduces a material accessibility regression, and it should commit the supplier to periodic reassessment as WCAG or UK expectations change. These clauses do not guarantee a perfect product. They do create a process for discovering and correcting problems before they become user harm or reputational damage.

An accessibility statement is a disclosure. Procurement needs proof. In 2026, UK buyers should treat accessibility as a testable product requirement, with evidence, remediation and remedies attached. That approach is fair to suppliers that have done the work, and considerably safer for the organisations that depend on them.