Accessibility Vendor Scorecards: Scoring Third Party Tools Before They Cost You

2026-10-16

A striking share of the barriers in any audit arrived through procurement, not development. The chat widget traps focus, the cookie tool hides its reject path from keyboards, the video player controls have no names. Each was bought on a slide that said fully accessible, and each became the buyer legal problem the day it shipped.

A scorecard moves the discovery to before the signature, when the buyer has leverage. It does not require deep expertise to run the basic version. It requires refusing to accept a conformance claim at face value and testing the product the way disabled customers will meet it.

Test tasks, not claims

Define three to five core tasks a customer performs with the tool: opening the chat and sending a message, completing the embedded form, playing and pausing the video. Test each by keyboard alone and with a screen reader, and score completion, errors, and time. A vendor that cannot complete its own core tasks accessibly has told you the most important fact in the evaluation.

Ask for the conformance report and read it like an auditor: which version of the product it covers, which standard and level, who produced it, and how much is listed as supports versus partially supports or does not support. A vague or elderly report scores as a finding, not as reassurance.

Score the overlay and the exits

Vendor tools live in overlays, modals, and iframes, which is where focus and labeling failures concentrate. The scorecard should specifically test focus entering the widget, visibility of focus inside it, the escape route back to the page, and whether page content behind an open widget is properly inert.

Also score the admin side lightly and the support channel seriously. When your audit later finds a barrier in their tool, the remediation path is their roadmap and their responsiveness. A vendor with no accessibility contact or history of fixes is a long term liability whatever the demo showed.

Put the score in the contract

A scorecard without contract language is a wish. The agreement should name the standard the tool must meet, require notice and remediation timelines when the vendor ships a regression, and give the buyer an exit if a critical barrier goes unremedied. Vendors who genuinely invest in accessibility sign these terms routinely. Resistance to them is itself a score.

Rescore at renewal and after major vendor releases. Accessibility in a hosted tool can regress overnight without your team touching anything, which is precisely why the scorecard is a recurring instrument and not a one time procurement hurdle.

Frequently asked questions

Why do third party tools cause so many accessibility issues?

Because they are bought on feature demos and accessibility claims that nobody tests. Widgets like chat, video, and consent tools concentrate exactly the patterns, overlays, focus handling, custom controls, where barriers cluster.

What should an accessibility vendor scorecard test?

Completion of the tool core tasks by keyboard and screen reader, focus behavior entering, inside, and leaving the widget, labeling of controls, and the quality, coverage, and currency of the vendor conformance report.

What is a red flag in a vendor conformance report?

A report covering an old product version, produced by the vendor itself with nearly everything marked supports and no detail, or one the vendor cannot explain. Vagueness in the report predicts vagueness in remediation.

How do contracts enforce vendor accessibility?

By naming the required standard, setting remediation timelines for regressions and critical barriers, and including an exit right if critical issues go unremedied. Willingness to sign such terms is a useful vendor signal in itself.