Accessibility has moved from a late-stage procurement question to a contractual one, driven by public sector purchasing rules, sector regulation and a growing body of litigation. Buyers ask for an accessibility conformance report, usually in the VPAT format, and vendors supply one. Both sides then file it and move on. That is where the value leaks out.
A conformance report is a self-assessment. It states, criterion by criterion, whether the product supports, partially supports or does not support a requirement, with explanatory remarks. It is produced by the vendor, is accurate as at a date, and carries no commitment about the future. The most common answer across most reports is partially supports, which can mean anything from a minor contrast issue on one screen to a workflow a screen reader user cannot complete.
For a buyer, the report is useful input and insufficient protection. For a vendor, a well-handled accessibility commitment is a straightforward competitive advantage in regulated and public sector sales. In both cases what converts the document into something meaningful is a small set of contract terms covering the conformance claim, the explanation of gaps, remediation and currency.
Why conformance reports disappoint
The weaknesses are inherent to the format rather than evidence of evasion, and each one has a contractual counterpart.
- Self-assessment without verification, the report is produced by the vendor, and nothing in the format requires independent testing or discloses the testing method used.
- Uninformative partial support, partially supports appears against many criteria with remarks too brief to indicate severity, affected workflows or user impact.
- Point-in-time accuracy, the report describes a version, and products ship continuously, so a report can be materially out of date within months.
- Scope ambiguity, the report may cover a core product while the buyer uses modules, admin interfaces, mobile clients or documentation that were never assessed.
- No consequence for inaccuracy, where a claim proves wrong, the buyer's only stated remedy is often general breach, which is disproportionate and therefore unused.
The result is a document exchanged to satisfy a procurement step rather than to manage a risk. Buyers in regulated sectors increasingly cannot afford that, because the accessibility obligation sits with them regardless of what their vendor's report said, and a report is not a defence if the deployed product does not match it.
A criterion marked partially supports should carry remarks identifying what fails, which user interactions are affected and whether a workaround exists. Without that, the buyer cannot assess whether the gap blocks a core task or affects an edge case. Requiring substantive remarks for every non-supporting criterion is the single highest-value change a buyer can ask for, and it costs the vendor nothing it should not already know.
The five terms that make it binding
Each term below belongs in the agreement, with the conformance report attached as a schedule rather than exchanged as correspondence.
- Conformance representation. a representation that the product conforms to the stated level against named criteria as at the effective date, with the report attached as a contract schedule so its claims are contractual rather than promotional.
- Gap explanation and impact. a requirement that each non-supporting or partially supporting criterion is explained with the affected functionality, user impact and any workaround, at a level the buyer can assess.
- Remediation plan with dated milestones. a schedule of committed fixes for identified gaps, with dates and a reporting cadence, so remediation is tracked rather than promised in general terms.
- Update obligation on release. an obligation to refresh the report at defined intervals or on material release, and to notify the buyer if a change reduces conformance against any criterion.
- Testing method disclosure. a statement of how the assessment was performed, including the assistive technologies and browsers tested and whether any independent review was involved, so the buyer can weigh the claim.
A five-step roadmap for buyers and vendors
Step 1, Define the scope being assessed
Name the modules, interfaces, mobile clients, administrative consoles and documentation covered. Accessibility reports frequently assess the primary end-user interface while the buyer's workflow depends on an admin console nobody tested. Scope stated in the schedule prevents an argument later about what the claim covered.
Step 2, Require substantive remarks on every gap
Ask for the affected functionality, the user impact and any workaround for each criterion not fully supported. This is the step that makes the report usable for risk assessment rather than for filing, and it also tends to improve the quality of the vendor's own internal view, in the way that building a clause library your legal team trusts improves drafting as a side effect.
Step 3, Convert gaps into a dated remediation plan
Agree which gaps will be fixed, by when, and how progress is reported. Dated milestones give the buyer proportionate recourse and give the vendor a defined commitment instead of an open-ended expectation. Track each milestone as an obligation with an owner.
Step 4, Tie currency to the release cycle
Agree that the report is refreshed on a defined cadence and on material release, with notification if conformance decreases. A product that ships every two weeks cannot be governed by an annual document, and a decrease in conformance is exactly the event a buyer needs to hear about.
Step 5, Standardize the schedule across the portfolio
For buyers, use one accessibility schedule across software agreements so claims are comparable and tracking is uniform. For vendors, maintain one current report and one standard schedule so each deal does not become a bespoke negotiation, which is the same cure for SaaS deal desk bottlenecks.
Track accessibility commitments as obligations
Aavenir holds conformance claims, remediation milestones and report refresh dates as monitored obligations on each software agreement.
The vendor's side of the argument
Vendors sometimes treat accessibility commitments as risk to be minimized, which is a mistake in markets where public sector and regulated buyers have procurement rules they cannot waive. A vendor that can produce a current, well-explained conformance report with a credible remediation plan removes a procurement obstacle that competitors will stumble on, and it does so with work the engineering organization largely has to do anyway. The contractual commitment is then a description of an existing practice rather than a new liability, which is a considerably more comfortable position than negotiating the scope of a representation under deal pressure.
Report weakness and contractual answer
The table maps each limitation of the conformance report format to the term that addresses it.
| Limitation | Contract term | Tracked as | Evidence |
|---|---|---|---|
| Self-assessed, unverified | Conformance representation | Representation at effective date | Report as schedule |
| Vague partial support | Gap explanation requirement | Reviewed at acceptance | Remarks per criterion |
| Known gaps unaddressed | Remediation plan | Dated milestones with owner | Progress reports |
| Report goes stale | Refresh on release or interval | Recurring obligation | Updated report, version |
| Scope unclear | Named scope in schedule | Confirmed at renewal | Scope statement |
An accessibility conformance report is a useful document doing a job it was never designed for. It records a vendor's self-assessment at a point in time; buyers treat it as an assurance about a product they will run for years. The gap between those two is closed by five terms: a representation that attaches the report to the contract, substantive explanation of every gap, disclosure of how the assessment was actually performed, a remediation plan with dates, and an obligation to keep the report current as the product ships. Tracked as obligations with owners rather than filed as procurement correspondence, those terms give a buyer something to rely on and give a vendor a clear, finite commitment instead of an open expectation.
For related guidance, see EU AI Act vendor contract clauses for technology buyers, The channel leader’s guide to reseller agreements and Auto-renewal clause risk in enterprise SaaS contracts.
