No. AI cannot make a website conformant with WCAG 2.2 by itself. It can identify candidate issues, draft alt text or code, and help route work. A scan report or accessibility widget is not a conformance decision. For example, a tool might flag a form control without a label; a person still needs to confirm the affected control, implement the fix, and test the form with a keyboard and assistive technology.
WCAG 2.2 is a W3C Recommendation. Conformance is assessed against defined criteria, scope, and level, and requires more than automated results. The W3C explains conformance requirements and recommends human evaluation, usability testing, and including people with disabilities in test groups. Its evaluation-tool guidance notes that tools cannot check every accessibility aspect and may produce misleading results. U.S. Department of Justice guidance likewise recommends combining automated checkers with manual checks.
Accessibility is relevant to a broad audience. The World Health Organization estimates that 1.3 billion people, approximately 16% of the global population, experience significant disability. This is a global disability estimate, not a measure of website visitors, lost traffic, or commercial impact.
A scan finds candidates; a reviewed and tested implementation supports a conformance decision.
What AI for web accessibility can and cannot do
Keep four stages separate when assigning work:
- Detection: a tool flags a possible issue, such as a missing alt attribute.
- Suggestion: AI proposes content or code, such as candidate alt text.
- Remediation: an authorized person changes the content or implementation.
- Conformance evaluation: the finished experience is assessed against a stated standard, level, scope, and test approach.
A scan result is a work item, not proof of accessibility. Evaluation should account for relevant pages, templates, dynamic states, and interactions. The W3C WCAG Evaluation Methodology provides a method for evaluating a representative sample. It does not certify that a product or vendor follows that method.
Choose rules, AI, or human review for each issue
Classify each check as deterministic, context-sensitive, or manual before assigning it. Use a reliable rule for an objective condition and reserve AI for bounded drafting or classification. A model should not replace a contrast calculation or be asked to infer whether a complete interaction is usable.
- Deterministic checks: missing alt attributes, missing document language, duplicate IDs, contrast calculations from known colors, and some label or ARIA relationships. A flagged condition may still need contextual review, but the underlying check does not require a generative model.
- AI-assisted proposals: draft alt text, suggest a clearer sentence, or explain a finding in plain language. Validate required fields and allowed values before the result enters a review queue.
- Human and assistive-technology tests: whether alt text communicates an image’s purpose, keyboard paths and focus behavior, dynamic announcements, and whether a form remains understandable when it reports an error.
A standard Lighthouse accessibility audit evaluates the currently loaded page. Wider coverage needs repeated runs or a separate crawl workflow. Interactive menus, modals, form errors, and single-page application states need to be exercised rather than assumed to be covered by an initial page load.
Build a human-reviewed workflow from scan to verified fix
Use an accessibility register or issue tracker as the system of record for findings, owners, decisions, and verification. The CMS should hold approved content, not unreviewed model output. Define the WCAG target and scope first, then make each handoff produce a record that can be checked later.
Use explicit states such as detected, needs-context-review, approved-for-fix, implemented, and verified. A modal finding cannot move to verified merely because a scan no longer reports it. The test owner should also exercise its keyboard behavior, focus handling, accessible name, and state changes.
Four implementation patterns for common accessibility work
These patterns are proposed workflow designs, not vendor API fields or ready-made integrations. A general AI assistant can receive a bounded request to explain a supplied finding or suggest a small code change. Do not imply that it crawls a site unless a specific, verified product capability supports that claim.
| Trigger and input | AI job and output | Validation and fallback | Destination and owner |
|---|---|---|---|
| A scan finding with rule, page version, DOM target, run ID, rendered state, and evidence. | Optionally classify the existing finding or explain it in plain language. Return a proposed status, WCAG mapping for review, and next action. Do not recalculate an objective rule with a language model. | Confirm the target, rule output, rendered state, and mapping. Route interaction-dependent, disputed, or duplicate findings to the accessibility lead. | Accessibility register or issue tracker. Engineering or content owner implements the accepted work. |
| An image placement with asset version, nearby heading, link purpose, and page context. | Draft alt text and classify the role as decorative, informative, functional, or complex. Return a pending review status rather than a publication command. | Content owner reviews ordinary informative images. Require specialist review for functional images, charts, diagrams, text in images, and ambiguous cases. Use an empty alt value for confirmed decorative images. | Approved CMS or asset-library value, with candidate and previous value retained. Content owner or accessibility specialist approves. |
| A reviewed component finding with relevant code, expected behavior, WCAG criterion, and test fixture. | Suggest a small patch, rationale, assumptions, and test ideas. Do not claim that generated code is conformant. | Engineer reviews the patch. Test focus order, accessible name, role and state, keyboard behavior, error handling, dynamic announcements, and relevant screen-reader output. Revert or rewrite broad patches. | Version-controlled change proposal. Component engineer owns implementation; accessibility reviewer checks interaction behavior. |
| New or replaced audio or video with media version, language, timecode source, and terminology list. | Draft transcript text and time-aligned caption segments tied to that media version. | Editor checks names, speaker changes, meaningful sound cues, punctuation, timing, and synchronization. Escalate uncertain speech or timing defects for manual correction. | Versioned caption or transcript asset. Media editor or captioning specialist approves before publication. |
Teams considering designing bounded AI workflows can apply the same approval and ownership principles without treating that service as an accessibility product or a conformance guarantee.
Hypothetical alt-text review record: the following fields are implementation guidance, not a vendor schema. The placement context and asset version prevent one approved description from being reused blindly in a different editorial setting.
{
"source_asset_id": "asset_105",
"asset_version": "v3",
"placement_context_hash": "specifications-page-heading-7",
"image_role": "informative",
"alt_text_candidate": "Draft for reviewer approval",
"reviewer_status": "pending"
}Hypothetical finding record: this record represents one issue instance from one detection run. The unique identity includes the run because the same target may be observed again in a later audit.
{
"site_id": "site_42",
"page_version_id": "pv_2026_10_13_01",
"rule_id": "example_rule_identifier",
"dom_target_hash": "illustrative_target_hash",
"detection_run_id": "run_2026_10_13_01",
"status": "needs-context-review"
}The same image can need different alt text in different placements. Track the asset version plus placement context, and deduplicate the asset without merging distinct editorial decisions. If the CMS lacks stable versions, combine an image-content hash with a placement identifier.
Keep findings, decisions, and evidence at the right data grain
For issue tracking, a useful proposed natural key is site_id + page_version_id + rule_id + dom_target_hash + detection_run_id. It distinguishes separate targets and repeated runs. Store an aggregate such as counts by template, rule, and reporting period in a separate summary, not in the same row as an individual finding.
Keep raw evidence, AI suggestions, reviewer decisions, published values, and rollback values distinct or versioned so that a later scan can reveal recurrence. For images, include asset version and placement context. For captions, use media asset version, language, and format. A page URL alone is not a reliable identity for either decision.
When concurrent crawlers may submit the same finding, do not rely on a lookup-then-create sequence. Enforce the chosen unique key in the database and use a transactional upsert or equivalent atomic write, while retaining a distinct run ID. These are proposed engineering patterns, not vendor-defined fields.
Evaluate tools by evidence, not by the word “AI”
Ask what the product actually tests, which WCAG version and criteria it maps, how it reaches pages and dynamic states, whether it changes source code or only the browser-rendered experience, what evidence it exports, and what still requires manual testing. Also check whether findings can be assigned and tracked in your existing system. Do not assume a direct API, export, or issue-tracker integration without verifying it.
Vendor statements are useful inputs, not independent accuracy tests. Siteimprove states that its product audits against WCAG 2.1 and 2.2 at Levels A, AA, and AAA. Its support documentation describes automated and semi-automated WCAG 2.2 testing rules. These statements establish reported product coverage, not complete conformance or independent accuracy.
EqualWeb describes its widget and explicitly states that a widget alone does not make a site ADA compliant. accessiBe states that accessWidget does not create captions or remediate documents. Its current pricing page lists traffic-based plans, including Micro at $59 per month or $490 per year, but pricing and terminology can change. The same page uses WCAG 2.1 Level AA language, while other accessiBe material references WCAG 2.2, so confirm the current version and scope directly with the vendor.
Current vendor pages also require careful qualification. Allyable describes A11yDev and A11yAudit and uses “WCAG 2.1+” language on its compliance page, rather than establishing uniform WCAG 2.2 coverage. UserWay’s current pricing page lists Pro at $490 per year and separate higher-tier plans with AI-powered remediation and additional monitoring. Siteimprove uses custom pricing. None of these statements independently measures accuracy, false-positive rates, false-negative rates, or remediation success.
A user preference control can be useful for adjustments such as text size, but it does not replace fixes to semantic structure, labels, focus handling, keyboard behavior, or source content. Ask vendors to identify the mechanism and exclusions for each claimed fix. Confirm current criteria, plan limits, pricing, and contractual scope directly with the vendor.
- A sample finding with its target, evidence, WCAG mapping, and stated test method.
- The remediation mechanism: source-code change, rendered-layer adjustment, or recommendation only.
- Specific exclusions, dynamic states, third-party components, and checks that still require a person.
- Post-fix retest evidence and a way to retain or export the finding history.
- A current quote and documented limits for your sites, pages, states, users, and review scope.
Measure whether the workflow improves accessibility operations
Set a baseline and review period before rollout. Track issue instances verified per review hour, calculated as verified issue instances divided by review hours; AI suggestion disposition, calculated as accepted, edited, or rejected suggestions divided by suggestions reviewed; recurrence, calculated as previously fixed instances found again divided by fixed instances rescanned; and time to verified remediation, measured from detection to verification with a defined median or other chosen statistic.
Keep these operational measures separate from site-level summaries. Report test coverage independently: pages and templates sampled, dynamic states exercised, assistive technologies used, browsers tested, and criteria manually reviewed. A higher scan score or fewer open findings alone does not show improved user experience or establish WCAG conformance.
Pilot on representative templates, inspect model suggestions and exceptions, and expand only when review capacity and named owners are in place. Document the scope and date for every reported metric so that future runs can be compared without confusing a new crawl with a verified remediation.