My insurance company provides an app. It handles claims, policy documents, and renewal. I cannot use it with VoiceOver (Screen reader). The buttons have no labels. Critical actions are buried behind gestures that do not translate to assistive technology. I have raised it. The response was sympathetic but unhelpful: the app is built and maintained by a third-party supplier, the contract is already in place, there is nothing they can do right now.

The insurance company did not build the app. They procured it. Somewhere, someone signed a contract with a vendor who delivered an inaccessible product. No one required them to do otherwise.

That is the exact scenario Sheri Byrne-Haber describes in her latest piece on procurement and accessibility. Her argument is one I wish I had been able to hand to someone before that contract was signed.

The Problem Happens Before the Product Arrives

Accessibility failures in third-party tools are not surprising. They are predictable. What makes them so damaging is the timing. By the time a screen reader user, a keyboard navigator, or someone with cognitive accessibility needs encounters the barrier, the leverage is gone. The contract is signed. The vendor has the money. You are the one fielding the complaint.

Sheri’s central point is that procurement contracts are where this gets fixed. Not in post-launch audits. Not in accessibility training for developers who built something six months ago. In the contract, before anyone starts work.

“Inaccessible third-party tools are one of the most common and preventable accessibility risks organisations face. The problem is that vendor accessibility failures are rarely discussed, much less demonstrated, during the sales process.”

Sheri Byrne-Haber, Accessibility Specialist and Advocate

Augmenting What Already Exists

This is what I find most compelling about Sheri’s framing: she is not asking organisations to create a new accessibility programme. She is asking them to make their existing procurement process do its job properly.

Procurement teams already write contracts. They already define deliverable standards. They already include indemnification clauses. They already specify legal compliance requirements. Adding accessibility language is not a new burden. It is an upgrade to work that is already happening.

This is how systemic change actually works. Not by building parallel processes that sit alongside the main business. By making the main business carry accessibility as a standard requirement.

Barclays has already done exactly this. Their external supplier requirements include a dedicated Digital Accessibility Standards section, requiring that all supplier-built digital products meet WCAG 2.2 AA (for web products) and EN 301 549 (for all digital products), covering everything from websites and mobile apps to ATMs, eLearning, and audio-visual content. They publish a dedicated accessibility guide for suppliers who are starting from scratch. They make the standard part of the contract before work begins. If one of the world’s largest financial institutions can do it, any organisation can.

The specific language Sheri recommends is concrete and enforceable. It requires vendors to meet WCAG 2.2 Level AA. It mandates an Accessibility Conformance Report (ACR) before delivery, based on the VPAT template. It makes remediation a defect correction, not a change of scope, so vendors cannot charge you to fix their own failures. It binds subcontractors to the same standards. And it includes indemnification that places liability with the vendor if their inaccessible product results in a legal claim against your organisation.

None of that is radical. It is specific. That specificity is the whole point.

Vague Promises Are Not Contracts

The failure mode Sheri identifies precisely mirrors what I have seen inside large organisations. Contracts say things like: “the vendor will make reasonable efforts toward accessibility.” That phrase is, as she puts it, legally “illusory.” It cannot be measured. It cannot be enforced. It is not a commitment. It is a placeholder.

The same applies to catch-all compliance clauses: “the vendor shall comply with all applicable laws and regulations.” That sounds robust. It is not. Laws change. Standards evolve. What is “applicable” is often contested. Specific language (WCAG 2.2 AA, ACR/VPAT, defined remediation timelines) is the only kind that holds.

Resources to Start With

If you are in a procurement team, a legal team, or an architecture role where vendor selection lands on your desk, you do not have to write this language from scratch.

Section508.gov publishes sample procurement language for federal use that is freely adaptable. The City of Boulder, Colorado, has made its actual vendor contract language public, including a well-drafted indemnification clause tied to the accessibility standards in effect at the time of delivery.

Closer to home, Barclays publishes its Digital Accessibility Standards for external suppliers, including a supplier accessibility guide, a full PDF of their standard, and a curated set of external resources for organisations starting their accessibility journey. Real contract language, from a real organisation, already in use.

None of these requires starting from scratch. That is the point.

Takeaway

Accessibility does not fail at the keyboard. It fails at the contract. If your organisation is buying digital products from vendors without specific, enforceable accessibility requirements in the agreement, you are absorbing their risk. The fix is available, it is free, and it starts before you sign.

Read Sheri’s piece. Send it to your procurement team. Ask when your next vendor contract is up for renewal.

Source: Locking In Accessibility: How Smart Procurement Language Protects Your Organization, published March 3, 2026.