Accessibility conformance evidence is a traceable body of information showing how a named version and configuration of a digital product or service was evaluated against the exact accessibility requirements in a procurement. It identifies the standard and level, scope, technologies, test method, evaluator, date, sample, supported user agents, criterion-level results, known limitations, user impact and remediation status. An Accessibility Conformance Report, including one prepared from a VPAT template where relevant, can organize claims. It is not a substitute for the testing and records that support them.
Accessibility answers often collapse into one of two unsafe sentences: “we are WCAG compliant” or “we will be compliant by go-live.” Neither tells an evaluator which product version, journey, content, criterion or test supports the claim. A scan with no manual checks is presented as certification. A corporate accessibility statement is attached for a different product. A report describes the standard release but not the configured solution in the bid. Known failures are hidden behind “partially supports,” while a roadmap date is written as though remediation were already delivered. The buyer cannot compare offers, and the delivery team inherits a promise whose scope and acceptance evidence were never defined.
Treat accessibility as a set of testable product obligations, not a brand adjective. First translate the buyer’s requirement into a conformance target for a named deliverable. Then build a claim ledger in which every statement points to current evidence, a disclosed limitation or a controlled future obligation. Scope complete user processes and all relevant ICT, not just the most polished web screen. Use automated checks for reach and repeatability, expert manual evaluation for criteria that require judgment, and disabled-user research for barriers and usability that conformance testing alone may not reveal. Never upgrade partial evidence into “certified,” and never present a remediation plan as present conformance. The strongest answer lets the evaluator see exactly what works, what does not, how it was tested and what the contract will require next.
Target
Translate the buyer’s words into an exact conformance target
Start with the procurement, not the company’s standard accessibility paragraph. Extract the named framework, edition, conformance level, applicable clauses, required template, evidence date, testing independence and delivery-stage obligations. “WCAG 2.2 AA,” “EN 301 549,” and the United States Revised Section 508 Standards are not interchangeable labels. They can overlap, but they may apply different requirements or scopes. EN 301 549, for example, addresses accessibility requirements for ICT products and services beyond web pages. A tender may also specify a buyer method, national rule or contract language. Preserve that structure and obtain qualified advice where applicability is a legal question.
Convert the text into a compliance record rather than one global claim. For each requirement, state whether it applies to the offered product, a configured deliverable, an implementation service, documents, support or a third-party element. Capture the requested response form and permitted values. In United States federal ICT procurement, an Accessibility Conformance Report can communicate how a product meets the Revised Section 508 Standards, and a VPAT may supply the reporting template. Section508.gov nevertheless describes an ACR as information used by buyers to assess accessibility. Its usefulness depends on specific product, version and criterion statements, not the template name alone.
| Field | Question | Evidence control |
|---|---|---|
| Authority | Which procurement clause or standard applies? | Quote exact reference and edition |
| Target | Which level or provisions must be met? | Map applicable criteria |
| Deliverable | Which product, service or content is assessed? | Name version and configuration |
| Stage | At bid, award, acceptance or operation? | Separate current and future state |
| Report | Which form and result terms are required? | Use buyer-prescribed structure |
| Exception | Who may determine an exclusion or exception? | Route to authorized process |
Scope
Bind every claim to a product baseline and complete process
Name the evaluated release, build date, deployment mode, configuration, platform, language, browser and assistive-technology baseline. List components the user must traverse: authentication, consent, search, forms, document upload, error correction, payment, reporting, help and logout where relevant. Include embedded services, generated documents and third-party controls if they are necessary to finish the task. WCAG 2.2 requires conformance at the full-page level and across every page in a complete process. A compliant marketing page therefore says nothing conclusive about an inaccessible checkout, application or case-management journey.
Sampling is useful only when the selection method can represent the product. The W3C WCAG Evaluation Methodology 2.0 lays out a procedure to define scope and target, explore the product, select a representative sample, evaluate it and report findings. Use structural samples for templates, states, technologies and critical functions, plus a reasoned random sample where appropriate. Record what was excluded and why. A report that says “twenty pages tested” without naming unique journeys or selection logic gives the buyer no way to judge coverage. Where the offered solution will be configured after award, identify the baseline already tested and the buyer-specific changes that require later evaluation.
- Identify the exact release and configuration, not only the product family.
- Cover complete tasks, including errors, alternate states and support routes.
- Include required third-party and generated content in the scope record.
- Explain representative sampling and preserve the full sample list.
- Mark every buyer-specific change that will invalidate or extend the baseline.
Evidence
Build criterion-level claims from test records
For every applicable criterion, record the result, tested sample, method, evaluator, date and finding reference. Automated tools are valuable for repeated checks such as detectable naming, structural patterns or contrast calculations, but they cannot decide many contextual requirements. Manual keyboard operation, visible focus, reading order, accessible names, status announcements, error recovery, zoom and reflow need qualified human judgment. Test with assistive technologies and user agents relevant to the declared support baseline. Involve disabled people to discover barriers and workflow costs that a pass-fail standards review may not expose, while keeping conformance decisions tied to the specified criteria.
Keep the summary report and underlying record aligned. If a criterion supports the claim only for part of the product, state the affected function and do not report an unqualified pass. If it does not apply, explain which product fact makes it inapplicable. If testing found a failure, describe the observed barrier, affected users, frequency, severity, workaround if one exists and issue reference. The W3C evaluation report guidance expects scope, reviewers, process and results to be visible. That context makes a claim reviewable. A large spreadsheet with every row marked “supports” but no method, version or finding is weaker evidence than a candid record with traceable results and bounded limitations.
| Element | Minimum record | Unsafe shortcut |
|---|---|---|
| Requirement | Standard, clause, level and applicability | WCAG compliant |
| Baseline | Product, version, configuration and scope | Current platform |
| Method | Manual step, tool, user agent and evaluator | Automated scan passed |
| Result | Sample, observation and evidence reference | Supports |
| Limitation | Function, users, impact and frequency | Minor issue |
| Action | Current fix, owner, verification and state | On roadmap |
Commitment
Disclose current gaps without turning the roadmap into evidence
Describe a limitation in terms an evaluator can use. Name the component and task, the relevant criterion, the observed behavior, who is affected, whether the task can still be completed, and the evidence behind any workaround. “Partially supports” without this detail can conceal anything from a cosmetic defect to a blocking keyboard trap. Do not call a workaround remediation. Do not declare an exception merely because a fix is expensive or a third party owns the component. The procurement or applicable authority determines permitted exceptions. The bid team should disclose the fact, route the conclusion correctly and avoid legal language it cannot support.
Separate four states in the response: tested current capability, configuration already included in the offered baseline, committed remediation with approved resources and acceptance evidence, and an uncommitted product roadmap. Only the first two can normally describe what exists now. A future obligation needs scope, owner, dependency, target, regression plan and objective acceptance test, plus commercial and legal approval. GSA guidance increasingly asks for more than a bare ACR, including evaluation methods and detail on known limitations and user impact. That is sound bid practice in any jurisdiction: disclose enough for the buyer to assess the offered outcome and for delivery to verify it.
Carry the evidence into the contract and release process. Define when buyer-specific configuration, new content, integrations and updates trigger retesting. Make accessibility defects visible in acceptance, not merely in a backlog after launch. Preserve the claim ledger, report, samples and issue records as a baseline. At each material release, retest affected criteria and complete processes, update the conformance report, and tell the buyer what changed. Accessibility evidence is credible when it survives product change and contract delivery, not when it is polished once for the tender.
- Describe the user and task impact of every known failure.
- Keep workaround, remediation, exception and roadmap as separate fields.
- Require authority, funding and acceptance evidence for future commitments.
- Retest configured journeys and third-party interfaces before acceptance.
- Refresh the report when product changes alter the evaluated baseline.
What good looks like
Useful outcomes from evidence accessibility conformance in a bid
- The bid addresses the exact accessibility standard, version, level and evidence form requested.
- Every conformance claim identifies the evaluated product version, configuration and user journey.
- Test reports expose method, sample, technologies, evaluator, date and criterion-level results.
- Known limitations describe affected users, tasks, workarounds and current remediation status.
- Current capability, award-time configuration and future roadmap commitments remain distinct.
- Accessibility verification and acceptance continue through implementation and product change.
Operating model
How to run the work
- 01
Parse the buyer’s accessibility requirement
Record the named standard, version, level, product scope, required report, evaluation stage, exceptions process and acceptance obligation without replacing them with a familiar internal label.
- 02
Fix the evaluated product baseline
Name the product, release, configuration, languages, platforms, user roles, complete processes, documents, support content and third-party components covered by each claim.
- 03
Assemble criterion-level test evidence
Link each applicable requirement to an evaluation result, method, sample, tool or assistive technology, evaluator, date, finding and retained test record.
- 04
Disclose limitations and future work
State the affected function and user impact, distinguish workaround from correction, assign remediation, and reserve any exception conclusion for the authorized buyer or legal process.
- 05
Commit to delivery and acceptance controls
Define testing for configured changes, evidence refresh, defect handling, regression, disabled-user involvement and the artifacts that will support contractual acceptance.
Evaluation
Questions that change the decision
- Which accessibility standard, edition, level and procurement clauses apply?
- What product version, configuration and complete user processes are in scope?
- Which criteria apply to web, software, documents, hardware, support or other ICT?
- What evidence format and evaluation independence does the buyer require?
- Which claims are supported, partially supported, not supported or not applicable?
- What user impact and evidence support every partial or failed result?
- Which remediation exists now, before award, during implementation or only on a roadmap?
- How will accessibility be retested and accepted after configuration and change?
Failure modes
Where teams lose control
A general accessibility statement may be mistaken for evidence about the offered product.
An automated scan may miss keyboard, focus, semantics, error recovery and assistive-technology barriers.
A sampled evaluation may omit a unique template, state, language or complete process.
A report may name WCAG while ignoring broader ICT requirements in the procurement.
“Partially supports” may conceal a blocker unless user impact and affected function are explained.
A third-party component may sit outside the evidence while remaining essential to the user journey.
A planned fix may be written as present conformance and become an unowned delivery commitment.
Product updates or buyer configuration may invalidate evidence that is not versioned and refreshed.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- applicable accessibility requirements with criterion-level disposition
- critical user processes represented in the evaluation sample
- claims linked to versioned test evidence
- known limitations with user impact and remediation owner
- manual and assistive-technology checks completed for applicable criteria
- configured components retested before acceptance
- accessibility regressions detected and resolved by release
Questions
Common questions
Does an automated accessibility scan prove WCAG conformance?
No. Automated checks can find and repeat some tests, but many criteria require manual judgment, interaction and assistive-technology evaluation. Use a documented method that covers the complete product scope.
Is a VPAT the same as an accessibility certification?
No. A VPAT is a reporting template used to create an Accessibility Conformance Report. The value of the report depends on accurate scope, version, criterion-level claims, methods and supporting evidence. Do not call it independent certification unless a separate valid certification exists.
Can we promise accessibility by go-live if the product has known gaps?
Only make a future commitment after defining the affected requirements, remediation, resources, dependencies, approval, regression testing and acceptance evidence. Disclose the current state separately so the buyer is not led to read the target as present conformance.
How current should accessibility evidence be for a bid?
Follow the procurement’s stated date requirements. In every case, bind the report to a product version and review changes since testing. Retest affected components and journeys where releases or configuration have changed the baseline.
Sources
Primary references
- Web Content Accessibility Guidelines 2.2 World Wide Web Consortium
- WCAG Evaluation Methodology 2.0 World Wide Web Consortium
- EN 301 549 accessibility requirements for ICT European Telecommunications Standards Institute
- Accessibility Conformance Reports for ICT procurement United States General Services Administration
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Ziva
Proposal software for source-grounded RFP, RFI, DDQ and questionnaire response work.
Bid, proposal, presales, security and compliance teams. Start with the workflow, constraints and evidence you already have.