Accessibility deliverable acceptance is a decision about whether agreed work and evidence meet a specified scope. An automated score alone does not establish WCAG conformance.
Substantively revised October 20, 2026. Author interpretation, documented cases and hypothetical examples are distinguished below.
Direct answer
Accept an accessibility deliverable against a written scope and inspectable evidence, rather than a single automated score. Identify the pages, states, processes, standard version and target level included in the work. Ask which checks were automated, which required human evaluation and what remains unresolved. Decide separately whether the supplier completed the agreed assessment, whether specified repairs passed retesting and whether the evidence supports a conformance claim.
A report can be a correctly delivered assessment of an inaccessible website. Accepting that report does not mean accepting the website as accessible. Equally, an excellent automated result does not establish that someone can complete a task with a keyboard or understand an incorrectly described image. The acceptance decision must name the output being accepted and the claim its evidence can actually support.
This article addresses the operational review of website service work. It does not determine a site's legal obligations or certify conformance. The examples use invented organizations and quantities where labeled. The proposed Claim-to-Check Map is an editorial framework for organizing a decision; it is not an additional accessibility standard or a replacement for evaluation by a competent specialist.
Key takeaways
Separate assessment, remediation and conformance. They are related outputs with different acceptance evidence. A supplier may identify barriers without being engaged to repair them. A developer may repair specified defects without having evaluated every applicable requirement. A buyer should not widen either result into a site-wide statement that no reviewer actually investigated.
Scope must include relevant interactions and states, not just a list of home-page URLs. Record evidence against the tested version and retain unresolved findings. Use automated tools to support a wider evaluation, with their limitations visible. When uncertainty affects a consequential public claim, narrow the claim or obtain the missing evaluation instead of promoting a score into a guarantee.
Definitions: what is being accepted?
An assessment deliverable describes an evaluation: its scope, methods, findings and limits. A remediation deliverable changes a specified defect and supplies evidence of the result. A conformance claim states that defined content satisfies the applicable requirements of a named standard and level. The three outputs can appear in one engagement, but their acceptance conditions should remain explicit.
WCAG is the Web Content Accessibility Guidelines, published by the World Wide Web Consortium. W3C's explanation of WCAG 2.2 conformance addresses full pages and explains the role of both automated and human evaluation. A checkout flow is not adequately represented by a screenshot of its first screen. The relevant relationship is between the claimed scope and the content and processes that users must encounter. [S1]
A finding is an observed problem with sufficient context to investigate. Test evidence records what was exercised, under which conditions and with what result. A score summarizes a selected set of tool checks. These objects should not substitute for each other. A numerical summary can help prioritize work while still being insufficient to accept a broader statement about users' ability to complete a process.
Observation: a green report can hide an unfinished purchase
Imagine a buyer opening a supplier's handover package. The first page displays a perfect accessibility score. The buyer approves the project. Later, a customer using a keyboard cannot close a modal that appears after an unsuccessful payment. The score may faithfully represent the tool's run, while the acceptance decision still exceeds what was examined.
The revealing detail is the state change. The website is not one static object: validation errors, expanded menus, consent panels and third-party widgets alter what a user encounters. If the handover evidence records only initial page loads, the buyer cannot infer that every interaction works. The failure is partly technical and partly a mismatch between the scope of testing and the scope of the promise.
Look for acceptance phrases such as “all green,” “no violations” or “fully compliant” without a named standard, version and scope. Ask what those phrases mean in the actual report. A clear limited result is more useful than a broad unsupported assurance, because it tells the next worker what remains to investigate. Confidence without boundaries makes later repair harder to plan.
Root cause: the deliverable and the claim have been collapsed
A service engagement often begins with a loose instruction to make a website accessible. That instruction combines diagnosis, design, implementation, evaluation and public communication. When the engagement reaches sign-off, everyone can point to completed work while disagreeing about what completion means. A scanner report becomes the easiest shared artifact, even if it was never capable of answering the entire question.
Another cause is a missing evaluation environment. A finding observed on one content version may disappear after a change, while a new template introduces a different barrier. Without a version reference and test conditions, a buyer cannot tell whether the report describes the delivered website or a previous build. An apparently thorough document can therefore be difficult to use for the immediate acceptance decision.
There is also an incentive problem. A supplier may be rewarded for reducing a visible count, and a buyer may be rewarded for closing a procurement task. Neither incentive guarantees that the remaining barriers are understood. The remedy is to require evidence appropriate to the claim and retain the unresolved list, including items whose importance is poorly represented by the scanner's score.
Framework: the Claim-to-Check Map
The map has five components: Output, Boundary, Method, Finding and Decision. Output states what the supplier is delivering: an assessment report, named repairs or a wider evaluation supporting a specified claim. Boundary describes the content, version and interactions to which that output applies. Method explains how the evidence was produced. Finding preserves the result and uncertainty. Decision records what the buyer accepts and what remains open.
Start with Output because it prevents a common category error. For an assessment, ask whether the report supplies a usable inventory of evaluated content, methods and findings. The acceptance criterion is not that the website has no problems. For a repair engagement, ask whether each agreed defect was changed and retested, with regressions considered within the agreed scope. Do not retroactively convert a repair list into a comprehensive audit.
Boundary should be specific enough that another evaluator can identify the content. Record the release or build, relevant URLs, user roles and important interaction states. If production differs from staging, state that difference. A payment provider, content management plugin or uploaded document may affect the experience even when it is outside the developer's preferred code boundary. Exclusion from a supplier's work does not make an obstacle disappear for users.
Method connects each assertion to a check capable of supporting it. An automated result can establish what that tool detected on a recorded run. A keyboard check can document an exercised sequence. A specialist's manual evaluation can address criteria requiring judgment. Avoid implying that one method has universal coverage. For high-consequence claims, request the missing competence or evidence rather than inventing a weighting formula that averages uncertainty away.
Finding includes reproducible steps, expected behavior, actual behavior and affected context. Decision distinguishes accepted, returned for correction and accepted with explicitly bounded outstanding work. A buyer can accept a report and open remediation work at the same meeting. Record who owns each unresolved item and what evidence is required before making the next public claim.
Three documented examples of evidence boundaries
W3C's Understanding Conformance explains that conformance applies to full pages and that evaluation involves automated testing and human judgment. Its discussion includes changing content and third-party contributions. The practical lesson is to inspect whether the scope of a claim corresponds to the actual experience. This source defines requirements and explains their meaning; it is not evidence that any particular website meets them. [S1]
Chrome's Lighthouse documentation describes its accessibility score as a weighted average of included audits and states that manual audits do not affect the score. That is a documented limit on the summary number. A buyer who sees a high score should ask for the manual evaluation evidence separately instead of assuming it is already represented in the total. [S2]
W3C's Easy Checks offers a first review of accessibility, including checks that can reveal useful problems early. It explicitly frames that review as limited rather than comprehensive. This is a real example of a helpful activity that should retain its modest claim: finding an obvious barrier can guide a repair, but a preliminary review cannot establish that no other barriers remain. [S3]
These sources support different questions. The conformance explanation defines the broader claim; the Lighthouse documentation explains the tool summary; Easy Checks supplies an initial review path. Keep their roles separate in the handover. Combining three links in a bibliography is not the same as connecting a specific acceptance assertion to the evidence that supports it.
Case study: accepting an assessment without accepting an inaccessible flow
Consider a hypothetical membership organization commissioning a website review. It has 12 content templates and a registration flow with 4 steps. The engagement covers an assessment and a prioritized defect report, not remediation. The buyer's internal checklist originally says “approve accessibility.” These quantities and circumstances are invented for the example; they are not reported results from a real organization.
The Claim-to-Check Map changes Output to “accept the agreed assessment deliverable.” Boundary identifies the evaluated release, selected pages, registration states and exclusions. Method records automated scans and the manual checks actually performed. Finding distinguishes confirmed problems, untested areas and observations requiring specialist follow-up. The acceptance meeting can now assess the quality of the report without pretending the underlying website is ready for a broad conformance statement.
Suppose the report contains 9 findings, of which 3 affect the registration flow. The buyer asks whether each finding includes reproduction steps and a connection to the relevant requirement. A missing screenshot might be replaceable by a clear written sequence; a missing explanation of the tested state is harder to compensate for. The aim is usable evidence, not decorative completeness or a fixed number of attachments.
The buyer accepts the assessment after the supplier clarifies an ambiguous exclusion. It opens a separate remediation task for the registration barriers and keeps the public accessibility statement aligned with known limitations. This is progress without fictional closure. A later repair review will examine the changed flow and its evidence, rather than treating the original assessment approval as proof that the repairs succeeded.
Application: make a repair retest traceable
For each agreed repair, retain the original finding identifier and the delivered change reference. Record the steps used to reproduce the original problem, then exercise the changed behavior in the relevant environment. A comment saying “fixed” is a status assertion. A retest record explains what someone actually observed. Both are useful, but they perform different jobs in acceptance.
Check important neighboring behavior where the change could reasonably cause a regression. If a modal's focus handling changes, inspect opening, interaction and dismissal, including the return path. The exact evaluation should be chosen by someone competent in the component and requirements. Do not turn a short example in this article into a universal accessibility test script; it illustrates the need to follow the interaction through its consequences.
Version the evidence with the delivered work. A screenshot from the previous build can still explain the original defect but should not be presented as the retest of a later build. If a third-party script changes between evaluation and deployment, identify the resulting uncertainty. A buyer who cannot reproduce the evaluated environment should receive that limitation plainly before approving a claim based on it.
Failure example: accepting a percentage instead of a method
A hypothetical agency promises to improve a scanner score from 86 to 100. It meets that numerical target on the chosen pages. The buyer interprets the result as complete WCAG conformance, although nobody evaluated manual criteria or the error states. The agency may have fulfilled the narrow numerical task while the handover communication still encourages an unsupported conclusion.
Repair the acceptance language before closing the engagement. State which tool ran, what content it examined and what the number represents. Ask whether the desired business decision actually needs a broader evaluation. If so, commission or complete it. Changing the label on the score cannot supply missing evidence, and adding a disclaimer to an otherwise sweeping claim may still leave readers confused.
Tradeoff and counterargument
A reasonable objection is that a small website cannot afford an elaborate assessment for every change. The response is proportional evidence, competent prioritization and honest limits. A preliminary review can be valuable; a narrow repair can remove a real barrier. Neither needs to be described as a comprehensive certification to justify its cost. Smaller claims often make useful work easier to buy and evaluate.
Another objection is that acceptance checklists slow down delivery. They do when they repeat information without improving the decision. Keep the map attached to the actual deliverable and focus on uncertainty that changes sign-off. An evaluator's concise explanation of an untested process is more valuable than a large spreadsheet whose empty cells are silently interpreted as passing results.
Common mistakes
Do not treat an untested criterion as satisfied. Mark it as untested or outside the stated evaluation boundary and explain the implication. Do not aggregate severe barriers and cosmetic improvements into a single favorable average that conceals an unusable task. Do not assume desktop results describe mobile interactions or that one authenticated role represents every user path.
Avoid excluding embedded content from the user's experience simply because another vendor supplies it. Record the ownership and repair route while preserving the scope limitation. Avoid announcing a conformance level from a scanner screenshot. Avoid accepting remediation solely from the implementer's assertion when the agreed process requires a separate retest. Use the actual evidence and the actual scope, even when that makes the final decision less tidy.
Action plan
Before the next supplier review, write down the deliverable you intend to accept in one sentence. Identify whether it is an assessment, specified remediation or evidence for a broader claim. Ask the supplier for the evaluated version and boundary. Read one finding from observation through reproduction and proposed action to see whether the report can guide a real repair.
At sign-off, compare claims with methods. Separate automated results from manual evaluation and mark uncertainty that affects the intended public statement. For a repair package, trace each agreed finding to a change and retest. Record unresolved items and their owners. Approve only the decision supported by this evidence, while leaving the next decision visible and achievable.
After deployment, confirm that the evaluated change is present in the delivered environment and that known version differences are understood. Plan a review trigger for meaningful changes to templates, interaction patterns or third-party components. Acceptance is a dated decision about an identified output, not permanent proof that a changing website will remain free of barriers.
FAQ
Does a perfect Lighthouse accessibility score prove WCAG conformance?
No. The score summarizes its included automated audits, while manual checks do not affect that score. Conformance requires evidence appropriate to the applicable requirements and the defined content, not an inference from the summary number.
Can we accept a report that finds serious problems?
Yes, if the engagement is an assessment and the report meets its agreed scope and evidence requirements. Keep that acceptance separate from any decision about releasing or describing the website itself.
Should the acceptance record name a standard version?
Yes, when a standards-based claim is involved. A vague promise to meet accessibility requirements leaves reviewers uncertain about the criteria and target level that the supplier actually evaluated.
What should we do with untested areas?
Identify them and explain their effect on the intended decision. Obtain additional evaluation when needed, or narrow the claim. An empty cell should never quietly become a passing result.
Is a preliminary review useful?
It can reveal important barriers and guide early repairs. Preserve its limited scope, as W3C's Easy Checks does. Useful initial evidence is still different from a comprehensive evaluation.
Do third-party widgets matter?
They can affect the user's experience and the scope of a claim. Record what was evaluated, what remains uncertain and which party can repair it rather than assuming external ownership removes the barrier.
Must every finding include a screenshot?
Not necessarily. Evidence should make the problem understandable and reproducible. Some interactions are better described through steps and observed behavior; screenshots alone may omit the state change that causes the barrier.
Who should perform manual evaluation?
Someone with competence appropriate to the criteria, technology and task. Buying a tool does not automatically supply that judgment. Ask the evaluator to describe methods and limitations plainly.
Can the developer retest their own repair?
They can provide useful evidence, but follow the agreed review process and obtain separate verification when it is required. Implementation and acceptance roles should be clear before the final meeting.
What happens if production differs from staging?
Identify the differences that could affect the result and inspect them as appropriate. Do not claim that evidence from one version automatically describes another with different content or scripts.
How should a limited repair be described publicly?
Describe the actual improvement without widening it into an unsupported site-wide claim. Keep known limitations and the applicable scope understandable to the people using the website.
Should we average all findings into one risk score?
Only if the method helps prioritization and preserves consequential barriers. A favorable average cannot compensate for a user being unable to complete an essential process or for missing evaluation evidence.
What is a useful acceptance condition for remediation?
The agreed defect is linked to a delivered change, the relevant behavior is retested and the result is recorded. Include the version and any remaining limitation that affects the decision.
Does user testing replace conformance evaluation?
No. They answer related but different questions. People using the service can expose important usability problems, while a standards-based claim still needs evaluation against the applicable requirements.
When should we revisit acceptance evidence?
When consequential content, templates, interaction behavior or dependencies change. Set a practical trigger that matches the scope of the original claim rather than treating one review as permanent coverage.
Recommended books
Accessibility for Everyone by Laura Kalbag is a useful introduction to considering accessibility across a project. Read it to improve the questions asked during planning and acceptance. It does not replace the current requirements, a competent evaluation or specific evidence about the delivered website.
A Web for Everyone by Sarah Horton and Whitney Quesenbery connects accessible design with people and their varied needs. It can help a buyer understand why a technical summary is only part of the delivery conversation and why the actual task matters when examining a report.
Inclusive Design Patterns by Heydon Pickering provides concrete design and implementation discussions. It is useful when evaluating whether a proposed repair fits the component's behavior. Treat examples as material to understand and test in context, rather than proof that copying a pattern makes an entire site conformant.
Further exploration
Take one existing supplier handover and underline every claim of accessibility. For each, identify the version, boundary and method that supports it. Where the connection is missing, ask for clarification before widening the claim. The resulting map should make useful work easier to accept and remaining work easier to commission, while keeping unsupported assurances out of the final decision.
Primary evidence sources
- [S1] W3C WAI: Understanding Conformance
- [S2] Chrome Developers: Lighthouse accessibility score
- [S3] W3C WAI: Easy Checks, a first review of web accessibility
Related concepts: systems thinking, wealth structure, and the survival loop. Read the editorial policy and citation guide.