The Internal Tool Nobody Tests with a Screen Reader

The problem is upstream of the product

When a new HR platform, case management system or rostering tool arrives in an organisation, the accessibility audit — if it happens at all — tends to happen afterwards. IT tests whether it integrates with existing infrastructure. Security tests whether it leaks data. Finance checks the licensing model. Nobody checks whether a blind employee can log a holiday request without calling the helpdesk.

The result is predictable. Employees who use screen readers, switch access or voice control encounter interfaces that were built without them in mind and procured without anyone asking. They raise the issue. The issue is logged. The vendor is contacted. The vendor says it is on the roadmap. Months pass. The tool is renewed.

This is not a technology mystery. Screen readers have been a mainstream assistive technology for decades. The Web Content Accessibility Guidelines — WCAG — have been publicly available since 1999, with version 2.1 published in 2018 and widely adopted as the benchmark for digital accessibility in the United Kingdom and internationally. There is no shortage of technical guidance. The shortage is of procurement processes that treat accessibility as a condition of purchase rather than a feature request.

What vendors know vendors can get away with

Accessibility Conformance Reports — ACRs — based on the Voluntary Product Accessibility Template (VPAT) are the standard mechanism by which software vendors document how their product performs against accessibility criteria. In principle, a procurement team should request an ACR, review it against WCAG 2.1 AA, identify gaps and use those gaps as a basis for negotiation or rejection.

In practice, ACRs are frequently out of date, covering an earlier version of the product than the one being sold. They are sometimes completed by the vendor's own team rather than by independent testers, and they use language — "supports with exceptions", "partially supports" — that obscures the severity of what does not work. A screen reader user who cannot navigate a dropdown menu does not care that it "partially supports" WCAG 1.3.1, the success criterion requiring information and relationships to be conveyed programmatically. They care that the form does not work.

Procurement teams rarely have the in-house expertise to interrogate an ACR line by line. That is a resolvable problem. Third-party accessibility auditors exist specifically to evaluate software against WCAG criteria, including with disabled testers using real assistive technologies. The cost of a pre-procurement audit is almost always lower than the cost of deploying an inaccessible system and managing the fallout — adjustments for individual employees, reputational risk, and potential claims under the Equality Act 2010.

Large employers are covered by the duty to make reasonable adjustments. When an internal tool is inaccessible, the organisation cannot simply point at the vendor. The obligation sits with the employer. That is the legal context. The practical consequence is that accessibility due diligence in procurement is not discretionary; it is risk management.

What a testable clause looks like

The difference between an accessibility commitment that survives and one that evaporates lies almost entirely in how it is written into the contract. A policy statement in a vendor's sales deck is worth nothing. A general commitment to "industry-standard accessibility" is nearly as worthless, because it is unverifiable.

A clause in the contract that holds over the life of an agreement needs several elements. First, it should name the standard: WCAG 2.1 Level AA as a minimum, or WCAG 2.2 if the contract is being signed now, since 2.2 was published in 2023 and is increasingly the working benchmark. Naming the standard removes the room to argue about what "accessible" means.

Second, the clause should require the vendor to provide an independently audited ACR — not a self-certified one — at the point of contract and at each major release or renewal. Independent here means audited by a third party not in a commercial relationship with the vendor. The clause should specify who bears the cost: the vendor, not the buyer.

Third, remediation timelines matter and must be explicit. When an audit identifies failures against named success criteria, the contract should specify that critical barriers — those that prevent a user from completing a core task — are remediated within a defined period. Ninety days is a reasonable starting point for critical issues; less critical issues might have a six-month window. Without defined timelines, "on the roadmap" becomes a permanent holding position.

Fourth, the contract should include a right to audit. The buyer — or a buyer-appointed auditor — should be able to test the live product at any point against the named standard, not just at the point of sale. This matters because software is updated continuously, and a product that passes an audit in January may introduce barriers by March.

Fifth, there should be a remedy. If the vendor fails to meet the standard within the agreed remediation window, the buyer needs a contractual mechanism: a right to withhold part of the fee, a right to exit the contract without penalty, or both. Without a remedy, the clause is an aspiration.

What to ask before signing

The conversation with a vendor before contract should cover a small number of specific questions. Does the product currently have an independently audited ACR against WCAG 2.1 AA or 2.2? If not, when was the last audit, who conducted it, and what version of the product did it cover? Which WCAG success criteria does the product currently fail, and what is the vendor's documented plan to address those failures? Can the vendor provide access to a working environment for independent accessibility testing before signature?

The answers to these questions are more revealing than the answers to almost any other due diligence question, because vendors who take accessibility seriously can answer them quickly. Vendors who do not will deflect, promise future documentation or offer the sales deck again. That response is itself the due diligence outcome.

Testing with real users — including disabled employees who actually use assistive technologies with this class of software — should happen before a system is selected, not after it is deployed. A composite user-testing panel reviewing three candidate platforms over two days costs a fraction of what an inaccessible enterprise deployment costs in adjustments and workarounds over a three-year contract term.

The internal tool nobody tests with a screen reader is not, in the end, a technology problem. It is a procurement decision made by people who did not ask the question. The question is not complicated. The question is: can everyone in this organisation use this?