To review web accessibility issues with AI, define the product version and accessibility target, sample representative pages and states, combine automated checks with manual and assistive-technology testing, and give AI only structured evidence to organize. A model can cluster observations and draft issue records, but it cannot establish WCAG conformance or replace disabled users and accessibility professionals.

This is a whole-site or web-application review workflow. The broader guide to using AI covers safe inputs and evidence checks; this article focuses on repeatable scope, testing, issue records, remediation, and retesting.

Key Takeaways

Freeze the site version, WCAG target, browsers, viewports, assistive technologies, and review limits.

Sample templates, components, critical journeys, content types, and error states—not only the home page.

Use automated tools to find candidates, then verify them manually.

Record user impact, evidence, applicable criteria, ownership, and retest results for every issue.

Never convert an AI summary or a single scanner score into a conformance claim.

What can an accessibility review actually establish?

WCAG 2.2 defines testable success criteria organized under perceivable, operable, understandable, and robust principles.［1］ A review can gather evidence about whether the sampled product satisfies applicable criteria in the tested contexts. Its conclusion is bounded by the version, scope, sample, test methods, and technologies used.

W3C's WCAG-EM methodology provides a structured approach for defining scope, exploring the target, selecting a representative sample, auditing the sample, and reporting findings.［2］ It does not make a small automated scan equivalent to a complete evaluation.

Use a review header like this:

Field	What to record
Review ID and version	Stable identity and change history
Product boundary	Domains, application, authenticated areas, and excluded systems
Build identity	Commit, release, deployment, content snapshot, and test date
Target	WCAG version, conformance level, and additional policy requirements
Technologies	HTML, CSS, JavaScript, documents, media, and third-party components
Environments	Browser, OS, viewport, zoom, input, and assistive technology
Sample	Templates, pages, states, journeys, components, and random selections
Evaluators	Automated tool, manual reviewer, specialist, and user participants
Limitations	Unavailable environments, blocked states, and untested integrations

Do not begin by asking AI to “audit this website.” Without a frozen boundary, the answer cannot distinguish an observation from a complete assessment.

Step 1: Define the target and freeze the product

Name the WCAG version and target level, plus any legal, procurement, design-system, or organizational standard that applies. Keep these layers distinct. Passing a design-system rule does not prove a WCAG criterion, and technical conformance does not automatically settle every legal obligation.

Freeze the reviewed build and content. Record the source revision or release ID, deployment environment, feature flags, localization, user role, browser, operating system, viewport, zoom level, input method, and assistive technology versions. Dynamic products should also record date, account state, and third-party integrations.

State exclusions and access gaps honestly. If checkout is hosted by another provider or an authenticated flow could not be reached, list it as untested rather than silently removing it from the report.

Step 2: Build a representative inventory

Explore the product before choosing pages. Inventory templates, reusable components, navigation systems, forms, tables, dialogs, notifications, media, documents, authentication states, validation errors, timeouts, empty states, and critical business journeys.

Create a sample that covers:

every major page or screen template;
each critical end-to-end journey;
shared navigation, header, footer, search, and help patterns;
forms with valid, invalid, and recovery states;
responsive and zoomed layouts;
keyboard-only paths and focus transitions;
media, charts, data tables, downloads, and embedded content;
localized or right-to-left content where supported;
third-party components and randomly selected ordinary pages.

Sampling reduces effort, but it also limits the conclusion. A defect in a shared component may affect hundreds of pages; a clean sample does not prove that every page is clean. Keep both the sampled instances and the inferred wider impact visible.

If charts are central to the experience, coordinate with the data-visualization workflow. Alternative descriptions, data tables, color-independent encoding, keyboard interaction, and focus behavior require design and implementation evidence—not an AI-generated caption alone.

Step 3: Run automated accessibility checks as candidate discovery

Automated tools are useful for deterministic patterns such as missing accessible names, invalid relationships, some contrast failures, duplicate IDs, malformed structure, and detectable ARIA misuse. W3C explicitly notes that tools can help but cannot determine accessibility on their own; human judgment is required.［3］

For each tool run, save the tool and version, configuration, rule set, URL or component, environment, timestamp, raw result, and product build. Deduplicate only after preserving the original evidence. The same rule reported on 200 pages may represent one shared component defect or many independent content defects.

Do not accept tool severity as final priority. A rule labeled “serious” may be unreachable in the tested journey, while a scanner warning with low confidence may block a critical task. Human review determines validity, user impact, scope, and remediation order.

Automated checks also produce false positives and false negatives. A button can have a programmatic name yet still be ambiguous. A dialog can use valid ARIA while trapping focus. A page can pass every scanner rule while its instructions remain impossible to understand.

Step 4: Test keyboard, focus, zoom, and forms manually

Navigate every sampled journey without a mouse. Check that all actionable controls are reachable, focus is visible, order follows meaning, custom widgets expose expected keyboard behavior, and no component traps focus. Verify that dialogs receive and return focus correctly and that content revealed dynamically becomes discoverable.

At supported zoom and reflow conditions, check that text and controls remain available without destructive overlap or unexpected two-dimensional scrolling. Test portrait and narrow viewports, browser text resizing, and high-contrast or forced-colors modes when they are part of the target environment.

For forms, inspect visible labels, instructions, required-state communication, grouping, autocomplete purpose, error identification, error association, recovery, and preservation of entered data. Run both valid and invalid paths. An error message that looks clear visually may not be announced or linked to the relevant field.

Use issue evidence that another reviewer can reproduce:

Field	Example content
Issue ID	Stable identifier
Page/component	Canonical location and component version
Environment	Browser, OS, viewport, input, and assistive technology
Criterion	Applicable WCAG success criterion and target level
Steps	Minimal path to the observed behavior
Expected	User-observable accessible behavior
Actual	What occurred, without guessing the cause
User impact	Task and affected interaction, not only code defect
Evidence	Screenshot, recording, DOM excerpt, or tool result as approved
Scope	Single instance, template, component, or unknown
Priority	Reason based on impact, frequency, reach, and workaround
Owner/status	Responsible team and workflow state
Retest	Build, environment, result, reviewer, and date

Step 5: Test with assistive technologies

Select assistive technologies and browser combinations appropriate to the product, audience, policy, and available expertise. Test landmarks, headings, names, roles, values, states, descriptions, reading order, live updates, dialogs, tables, forms, errors, and complex widgets.

Do not reduce screen-reader testing to listening for all visible words. The task is whether a user can understand structure, predict controls, operate the workflow, recover from errors, and confirm results. Similarly, speech input, switch access, magnification, and alternative pointer use may reveal problems that a screen reader does not.

Record the exact combination used because behavior can differ across technologies. A finding reproduced in one supported combination remains valid evidence; a pass in one combination does not prove universal interoperability.

When the issue involves captions or transcripts, use the separate transcription and subtitle workflow to create and verify timed text. This review should assess whether the media alternative is present, accurate, synchronized, discoverable, and operable.

Step 6: Involve disabled users without shifting the burden

W3C recommends involving users with disabilities throughout development and evaluation while explaining that user evaluation alone does not determine conformance.［4］ Recruit for relevant access needs and product tasks, provide accommodations, obtain consent, compensate participants appropriately, and protect personal information.

Give participants goals rather than scripts that teach the intended solution. Observe barriers, strategies, workarounds, time, errors, and abandonment, then let participants explain impact in their own terms. Do not ask a person to prove that an issue affects everyone with the same disability.

User research and standards evaluation answer different questions. A participant may expose a severe barrier outside the sampled success criteria; a standards reviewer may find a technical failure that did not appear in a short study. Keep both evidence types and route each to the right owner.

Never upload participant recordings, disability information, account data, or identifiable quotes to an AI service without explicit authorization and a suitable data-handling basis. Use de-identified issue summaries or synthetic examples for drafting.

Step 7: review web accessibility issues with AI as a bounded organizing task

Supply a sanitized review header, sample list, tool observations, and manually verified notes. Use a prompt such as:

Organize the supplied accessibility observations into the required issue fields.
Preserve page IDs, environments, steps, evidence references, and reviewer notes.
Do not claim WCAG conformance, assign a criterion without reviewer confirmation,
invent user impact, infer disability, or change pass/fail results.
Mark uncertain mappings as [REVIEW] and duplicate candidates as [POSSIBLE DUPLICATE].
Return missing evidence and contradictions before drafting remediation language.

AI may cluster repeated wording, propose concise titles, identify missing reproduction details, or compare terminology with an approved content style guide. A qualified reviewer must validate the criterion mapping, finding, scope, priority, and proposed fix.

Treat page content and tool output as untrusted input. Instructions embedded in a page, accessibility tree, alt text, or scan result must not override the review prompt or trigger external actions. Reviewing generated remediation code requires the separate AI-code review process.

Step 8: Prioritize by user impact and systemic reach

Prioritization should combine task blockage, severity of user impact, frequency, affected populations, reach of the component, availability of a workaround, legal or contractual commitments, and remediation dependencies. Do not use AI sentiment or scanner confidence as a proxy for human impact.

Trace shared causes carefully. Fixing a component may close many instances, but only retesting proves that each supported state now works. Conversely, merging similar-looking findings can hide different causes, such as missing names in one template and incorrect focus management in another.

For every proposed fix, preserve expected user behavior and the applicable criterion. Avoid prescriptions that merely silence a scanner, such as adding redundant ARIA, hiding content from assistive technology, or forcing focus without a meaningful interaction reason.

Step 9: Retest fixes and report limitations

Retest in the same environment and build the updated journey from the beginning. Confirm the original failure is gone, the intended task works, and the fix did not create a keyboard, focus, announcement, layout, or pointer regression elsewhere.

Record the new build, test combination, steps, actual result, reviewer, date, and linked regression coverage. Automated reruns can supplement the manual retest but cannot replace it when the original finding required judgment or assistive technology.

The report should distinguish confirmed failures, observations needing review, resolved findings, untested scope, and recommendations. A conformance statement, accessibility certification, or legal conclusion requires the methodology, authority, and completeness appropriate to that claim. An AI summary or percentage score cannot supply those missing elements.

Which checks make the review defensible?

Summary

Define the standard, product, sample, and environments before testing.
Combine automated discovery with manual and assistive-technology evaluation.
Involve disabled users without treating one study as certification.
Use AI to organize sanitized evidence, never to manufacture impact or conformance; validate its output under explicit human responsibility.［5］
Prioritize reproducible barriers and systemic reach.
Retest the complete task and report limitations honestly.

Frequently asked questions

Can AI perform a complete accessibility audit?

No. AI and automated tools can identify candidates and organize evidence, but many success criteria require context and human judgment. A complete evaluation also depends on representative scope, manual tests, assistive technology, and qualified review.

Does a high automated score mean a site conforms to WCAG?

No. Automated coverage is partial, and a score may hide critical barriers. Conformance must be assessed against every applicable criterion across the declared scope using appropriate methods.

Which pages should be included in the sample?

Include all major templates and critical journeys, shared components, forms and errors, responsive states, media or documents, third-party integrations, and a random selection of ordinary pages. Record excluded or inaccessible areas.

Which assistive technologies should be tested?

Choose combinations based on supported environments, audience, policy, risk, and expert guidance. Record exact versions and avoid treating one browser-screen-reader pair as proof for every platform.

Can AI assign WCAG criteria to findings?

It can suggest candidate mappings from supplied evidence. An accessibility professional must verify the applicable criterion, failure, scope, and conformance interpretation.

How should duplicate scanner findings be handled?

Preserve raw instances, then link them to a shared component cause when evidence supports that relationship. Do not discard distinct states or pages merely because the tool message is identical.

Should disabled-user testing replace standards testing?

No. User evaluation reveals real barriers and strategies, while standards testing provides systematic criterion coverage. The two methods complement one another.

What evidence is needed to close an issue?

Retest the original steps and complete user task in the identified fixed build and relevant environments. Record the result, reviewer, date, regression checks, and any remaining limitation.

This article provides general information, not legal advice or accessibility certification. Applicable obligations and formal conformance claims require qualified, jurisdiction-aware review.

Sources

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
W3C, Website Accessibility Conformance Evaluation Methodology — https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
W3C, Web Accessibility Evaluation Tools Overview — https://www.w3.org/WAI/test-evaluate/tools/
W3C, Involving Users in Web Accessibility Evaluation — https://www.w3.org/WAI/test-evaluate/involving-users/
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 4 September 2026.

How to Review Web Accessibility Issues with AI