Accessibility AI claims need human evidence whenever they promise a conformance outcome, a barrier-free experience, or a legal-risk conclusion rather than a narrow, inspectable change. Automation can identify some detectable conditions, yet W3C’s guidance on evaluation tools is explicit that tools cannot determine accessibility on their own. The procurement question is therefore not whether an AI feature is impressive. It is what it changed, what evidence supports that change, and which qualified human reviewed the remaining uncertainty.
That distinction matters because Web Content Accessibility Guidelines 2.2, usually called WCAG, sets success criteria for web content, while a product claim may describe anything from code suggestions to a declaration that a whole site is “compliant.” Those are not interchangeable outputs. A generated alternative text suggestion is an input to review. A documented accessibility assessment is evidence about a defined scope, version, method, and result.
Claim language reveals the evidence burden
The useful dividing line is whether a claim describes assistance or assurance. “Suggests labels for unlabeled controls” is an assistance claim that can be inspected against the relevant content. “Makes your site accessible” is an assurance claim whose scope must include behavior, context, and people using assistive technology. W3C’s conformance-evaluation guidance describes evaluation as a process involving a selected sample, a defined evaluation procedure, and reporting, which is materially more demanding than demonstrating that a feature produces output.
| Claim type | Example wording | Evidence a buyer should require |
|---|---|---|
| Assistance | “Suggests alt text” | Samples, accuracy limits, human acceptance workflow |
| Detection | “Finds WCAG issues” | Mapped rules, test scope, false-positive handling |
| Assurance | “Makes pages compliant” | Independent assessment, user evidence, defined scope |
The table is a procurement framework, not a measurement of any vendor. Its logic follows from the difference between machine-detectable conditions and the broader evaluation expected by W3C’s accessibility evaluation guidance. A tool may be valuable at any row. Trouble begins when evidence appropriate to the first row is used to market the third.
Why generated fixes still require judgment
Alternative text illustrates the gap cleanly. WCAG 2.2 requires text alternatives for non-text content in many circumstances, but it also distinguishes informative images, decorative images, functional images, and more complex cases. W3C’s Images Tutorial explains that the right treatment depends on the image’s purpose in context. An AI system can propose words after interpreting pixels or nearby text; it cannot make the organizational decision about what information the image must convey to this audience in this task without an accountable reviewer.
The same problem appears in code remediation. A tool can add an Accessible Rich Internet Applications (ARIA) attribute, but Mozilla Developer Network (MDN) Web Docs’ ARIA reference cautions that native HTML should be preferred where possible and that incorrect ARIA can make an interface less accessible. The evidence burden is not met by showing a changed attribute. Review must establish the element’s semantics, keyboard behavior, name, state, and interaction with the rest of the interface.
Interpretation: AI is most credible when it reduces review effort without disguising review as optional. That framing is less glamorous than an autonomous-accessibility narrative, although it is more useful to a team that must defend a release decision later.
WCAG conformance is not a model-output format
WCAG is a technical standard organized around testable success criteria, but conformance applies to a full page, complete processes, and accessibility-supported use of technologies under stated conditions. Those boundaries are set out in the WCAG 2.2 conformance requirements. A dashboard score, a count of repaired elements, or a before-and-after screenshot may be useful operational evidence; none alone establishes conformance for an unspecified experience.
Legal language raises the burden further. The Americans with Disabilities Act (ADA) is a United States civil-rights law, and the U.S. Department of Justice web-accessibility guidance explains that state and local government web content must be accessible under Title II while also describing practical accessibility considerations more broadly. A vendor’s statement that its AI feature removes ADA exposure should prompt a request for exact scope, jurisdiction, exclusions, and legal basis. Product marketing is not an interpretation from an enforcement authority or a substitute for counsel.
FINDING: Evidence should travel with the claim. A screenshot supports that a screen changed. A rule report supports that selected rules ran. Neither document, by itself, supports a promise about every task, every user, or legal compliance.
Human evidence means more than a final sign-off
A human review that merely accepts a model’s answer is thin evidence. A defensible process assigns people to distinct questions: whether the claimed issue exists, whether the proposed change preserves function, whether the result satisfies the applicable criterion, and whether representative users can complete important tasks. W3C’s guidance on involving users in web accessibility evaluation explains why people with disabilities contribute perspectives that technical checks do not replace.
Human evidence also needs a record. For each substantial AI-assisted change, retain the page or flow, environment, date, tool and version, prompt or configuration where relevant, criterion or policy being evaluated, reviewer decision, and unresolved exception. This is an application of traceability, not a claim that every correction needs a committee. The U.S. Section 508 testing guidance provides a public example of structured test processes and documented outcomes.
Scope is where weak claims often hide. An interface may pass a limited automated scan while its checkout, authentication recovery, error messaging, or time-sensitive interaction remains unusable. W3C’s preliminary-review guidance characterizes early checks as a way to identify some barriers, not as a conformance evaluation. Buyers should insist that a proposed evidence plan names the journeys, templates, states, platforms, and assistive-technology combinations it does not cover.
Ask vendors for a claim-to-evidence map
Procurement can turn skepticism into a concrete request. Ask the vendor to map each accessibility AI claim to the specific capability, the evidence supplied, the human role, and the conditions under which the claim no longer holds. Ask whether generated changes are published automatically, whether reviewers can reject them, and whether the system preserves an audit trail. Ask for evaluation materials that distinguish detection rate from remediation quality, because the two measures answer different questions.
Governance teams should then run one representative, high-consequence workflow through that map before buying at enterprise scale. Select a flow with forms, validation, dynamic updates, and a meaningful completion state. Compare the vendor’s claimed scope with the evidence it provides, then have an accessibility specialist review the changes and include people with disabilities where the work affects real user tasks. This is not a universal certification procedure. It is a focused way to discover whether the claim and the evidence use the same unit of analysis.
LIMITATION: This investigation synthesizes standards and public guidance; it does not test a named AI product, estimate tool accuracy, or determine any organization’s legal compliance. Claims about a specific system require its versioned documentation and an evaluation of the relevant implementation.
Key takeaways
- Accessibility AI can provide useful assistance, but an outcome claim needs evidence proportionate to its scope.
- WCAG conformance depends on defined content, processes, and evaluation conditions, not on a generic dashboard score alone.
- Generated alternative text and ARIA changes require contextual human review because correct accessibility depends on purpose and behavior.
- User involvement adds evidence that automated checks and expert inspection cannot fully supply.
- A claim-to-evidence map is a practical procurement artifact for exposing unsupported assurances before deployment.
Questions readers ask
Can AI make a website WCAG compliant?
AI can assist with detecting or proposing changes, yet W3C’s tool guidance says automated tools alone cannot determine accessibility. A conformance claim needs evaluation evidence for a defined scope.
Is an accessibility score proof of compliance?
No. A score can summarize a particular tool’s checks, whereas WCAG 2.2 conformance requirements define a broader set of conditions for conformance.
Why is human review necessary for AI-generated alt text?
The appropriate text alternative depends on the image’s role and context, as W3C’s image guidance demonstrates. Reviewers decide whether the proposal communicates the information a user needs.
What should an enterprise ask an accessibility AI vendor?
Request a claim-to-evidence map: capability, scope, evaluation method, human review point, exclusions, and audit record. That request makes it possible to separate a bounded product feature from an unsupported assurance.