Scope and user needs
Users, tasks, assistive technologies, critical workflows, channels, requirements, and exceptions.
Free editable CSV
40 evidence-first checks
Buy accessibility as a requirement—not a post-launch repair project.
A vendor saying a product is “accessible” is not the same as showing which requirements apply, how the product was tested, where barriers remain, and what happens when accessibility regresses. Use this worksheet to turn accessibility into evidence, acceptance criteria, and an ongoing contractual obligation.
No email gate. This resource is general procurement guidance, not legal advice or a substitute for the accessibility standards and acquisition procedures that apply to your organization.
- Define before demoIdentify users, critical workflows, applicable requirements, and in-scope components before comparing vendor claims.
- Evidence over labelsAsk how claims were tested, what remains unsupported, and which version the evidence covers.
- Test the processValidate complete tasks with keyboard and assistive technology—not only isolated controls.
- Keep it contractualAccessibility should survive updates, configuration changes, support handoff, and the full contract term.
A procurement evidence model
Separate requirement, claim, test, and acceptance.
Accessibility reviews become difficult when those four things are blended together. The worksheet gives each review item a question, a reason it matters, evidence to request, a suggested owner, a “ready when” condition, and the risk created by a weak answer.
- 01
Scope the users and work.
Identify the people, assistive technologies, devices, environments, critical tasks, generated outputs, and administrative surfaces that belong in the evaluation.
- 02
Identify applicable requirements.
Document the standards, success criteria, contract clauses, exceptions, and organization-specific requirements that the delivered solution must satisfy.
- 03
Collect vendor evidence.
Request current ACR/VPAT material where appropriate, test methods, known-defect information, remediation plans, and product-specific demonstrations instead of accepting broad accessibility statements.
- 04
Validate representative workflows.
Use automated and manual methods, keyboard testing, screen readers or other assistive technologies, zoom/reflow checks, generated-document review, and realistic task scenarios.
- 05
Make accessibility an acceptance gate.
Define severity, ownership, cure expectations, retesting triggers, and the evidence required before accepting the delivered product or a material update.
40 accessibility checks
Eight areas that should have explicit evidence.
The downloadable worksheet includes five checks in each area and editable status and notes fields so the same evidence can travel from market research through technical evaluation and acceptance.
Vendor conformance evidence
Current ACR/VPAT material, test methods, product/version mapping, known defects, and independent evidence.
Keyboard and interaction
Keyboard operation, focus, complex widgets, timing, validation, and recoverable errors.
Screen readers and semantics
Names, roles, states, structure, announcements, voice-control labels, and representative AT tests.
Visual and content accessibility
Contrast, zoom and reflow, redundant cues, text alternatives, and motion controls.
Documents and authoring
Generated reports, PDFs, templates, authoring support, multimedia, and accessible help.
Testing and acceptance
Multi-method testing, human evaluation, defect governance, acceptance gates, and regression testing.
Contract and remediation
Ongoing obligations, remediation targets, release disclosure, training, validation rights, and cure language.
ACR review
Treat an ACR as evidence to evaluate—not the end of the evaluation.
A useful Accessibility Conformance Report should help the buyer understand what was evaluated, against which criteria, for which product/version, using which methods, and where support is partial or absent.
- 1
- Version. Confirm the report covers the product, platform, configuration, and release actually being purchased.
- 2
- Scope. Look for coverage of the interfaces, documents, authoring features, support content, and workflows that matter to the buyer.
- 3
- Method. Ask which tools, manual tests, assistive technologies, browsers, devices, and evaluators produced the claims.
- 4
- Specificity. Favor criterion-specific remarks and known limitations over generic “supports” statements.
- 5
- Disposition. Translate partial support and known defects into remediation commitments, acceptance decisions, or documented risk treatment.
Acceptance boundary
Do not let accessibility become a warranty conversation after go-live.
Define the test plan, critical workflows, severity model, defect thresholds, cure process, and retest evidence before the organization loses procurement leverage.
- Test the delivered configuration. Configuration, customizations, integrations, and embedded components can materially change accessibility.
- Include generated content. Reports, documents, exports, emails, and public-facing content should be evaluated when they are part of the delivered service.
- Track material defects. Give barriers an owner, severity, target, and explicit acceptance or risk decision.
- Plan for regression. Significant updates and component replacements should trigger renewed accessibility evidence.
Primary references
Use the worksheet with the requirements that actually govern your procurement.
The checklist is intentionally generic. For U.S. federal ICT procurement, Section508.gov says agencies should identify applicable requirements up front and request accessibility information from vendors, including an ACR for standard ICT where required. W3C publishes WCAG 2.2 as a web accessibility standard; your organization may be bound to a different incorporated version or additional requirements.
Continue the decision chain
Carry accessibility evidence into the RFP, scorecard, and acceptance plan.
Use the accessibility worksheet to establish evidence expectations, the RFP checklist to place those expectations in the solicitation, the vendor security questionnaire to collect parallel security evidence, and the software scorecard to keep tradeoffs visible during selection.