Can AI Make a Website WCAG Conformant? A Comprehensive Guide
Read the original on levelaccess.com ↗AI can’t make a website WCAG conformant alone. Properly skilled AI can find, fix, and prevent many violations, but validating conformance requires human judgment.
The Web Content Accessibility Guidelines (WCAG) are internationally recognized as the standard for web accessibility, and they’re referenced by laws and regulations around the world. Conforming to the latest version, WCAG 2.2, at Level AA is the north star for many organizations prioritizing digital inclusion. In practice, though, reaching this target can be a resource-intensive process.
If your team is already using AI to streamline web development, you may be wondering whether AI can save you time here, too. So, can AI make a website WCAG conformant—or at least speed up the work?
The short answer is that AI can’t make a website WCAG conformant on its own. Automated and AI tools can test against many success criteria and help fix violations. When they’re properly skilled, they can also build experiences that meet those criteria from the start. But conformance applies to full pages and complete processes, and several criteria depend on human judgment about meaning, order, and operability.
In this blog, we’ll explore what WCAG 2.2 conformance requires, where AI and automated testing can help, and where they reach their limits. You’ll also learn how to use properly skilled AI to fix and prevent issues, and how WCAG applies to the AI features you ship. Finally, we’ll go through a practical workflow for achieving WCAG conformance with AI in the loop.
Key insights
- WCAG 2.2 conformance applies to full pages and complete processes, so an automated scan can’t support a conformance claim on its own.
- Automation is dependable for objective checks such as 1.4.3 Contrast (Minimum) and 3.1.1 Language of Page. People still need to judge accuracy, meaning, order, and screen reader compatibility.
- General-purpose AI tools don’t build fully conformant experiences out of the box. With accessibility guidance, guardrails, an accessible design system, and human validation, AI can build experiences that meet most WCAG criteria.
- To comply with accessibility laws, the AI features you ship, such as chat assistants, as well as third-party AI content on your site, need to meet the same WCAG success criteria as the rest of your site.
- An effective workflow uses AI to build with guardrails, scan, prioritize, and fix, then relies on automated and manual evaluation (including testing with assistive technology) and recorded evidence to support conformance.
What WCAG conformance requires, and why a scan can’t make the final call
WCAG is a technical standard published by the World Wide Web Consortium (W3C). It organizes success criteria into three conformance levels: Level A, Level AA, and Level AAA. Each level includes the criteria below it, so Level AA conformance means meeting every Level A and Level AA criterion.
WCAG 2.1 Level AA is the standard most referenced by laws, but meeting WCAG 2.2—the latest version—future-proofs web accessibility compliance and provides access for a broader group of users.
WCAG 2.2 §5.2 sets five conformance requirements that every conformance claim has to satisfy:
- Conformance level: One level of conformance is met in full.
- Full pages: Conformance applies to full web pages only, and it can’t be achieved if any part of a page is excluded. A page can still conform through a conforming alternate version, such as a setting or style switcher that users turn on to meet the criteria. The way users reach that version has to be accessible itself.
- Complete processes: When a page is one step in a process (for example, a checkout flow), every page in that process conforms at the stated level or better.
- Only accessibility-supported ways of using technologies: Only uses of technology that assistive technologies and browsers support can be relied on to meet the criteria.
- Non-interference: Technology used in ways that aren’t accessibility supported, or that don’t conform, can’t block users from the rest of the page.
The second and third requirements explain why a scan alone can’t support a conformance claim. Automated scans evaluate the elements their rules can detect on the pages they reach. They don’t confirm that a full page works as a whole. They also don’t confirm that a person can complete a multi-step process like signing up, checking out, or recovering from an input error. A clean scan tells you the tool’s rules found no issues. It doesn’t tell you the page conforms.
WCAG anticipates this. The W3C designed WCAG 2.2 to be “testable with a combination of automated testing and human evaluation.” W3C guidance on evaluation tools makes the same point. Tools can help you quickly identify potential accessibility issues, but they can’t check every aspect of accessibility automatically. They can only assist in determining accessibility, not determine it themselves.
That doesn’t diminish what automation and AI can do. It defines where they fit.
The next major version, WCAG 3, could change how conformance works. It’s still a W3C Working Draft, most recently published on September 10, 2026, and it’s exploring a similar conformance model, but with additional reporting guidance. Until it becomes a standard, WCAG 2.2 remains the W3C’s official recommendation.
Which WCAG 2.2 criteria automated and AI testing covers, and which need people
WCAG 2.2 contains 86 success criteria. Level AA conformance covers 55 of them: 31 at Level A and 24 at Level AA. Automated and AI testing can’t tell you if you meet all 55. Some criteria have objective, measurable conditions that a rule can check reliably. Others need a person to confirm what a tool flags, and some depend almost entirely on human judgment.
The W3C’s Accessibility Conformance Testing (ACT) Rules are the standards body’s reference for testing content against accessibility standards by rule. ACT Rules can be fully automated, semi-automated, or manual. They also rarely test an entire success criterion, so passing an ACT Rule doesn’t necessarily mean the criterion is met. That’s the right way to read any automated result: as evidence about part of a criterion, not a verdict on all of it.
The following sections provide examples of WCAG 2.2 Level A and AA criteria where AI and automation are reliable, where AI is helpful but human validation is needed, and what needs to be left to people. The tables in each section are for illustrative purposes only: Interpreting a standard is a nuanced exercise, and advancements in AI are rapidly changing what’s possible.
Criteria where automation is dependable
Automated testing does its best work on criteria with clear, measurable conditions, like those in the following table. You’ll note that even when automation can provide mostly reliable results, certain aspects of conformance with many of these criteria still need to be validated by a person.
| Criterion | Level | Where AI and automation help | What needs human validation |
|---|---|---|---|
| 1.4.3 Contrast (Minimum) | Level AA | Automated scans reliably measure the contrast ratio of text on solid backgrounds and flag insufficient color contrast. | AI using computer vision can estimate contrast for text over images and gradients, but a person should confirm those results and decide whether exceptions apply. |
| 3.1.1 Language of Page | Level A | Automated rule checks can confirm that a page declares a valid default language. | This criterion rarely needs further review. |
| 2.4.2 Page Titled | Level A | Tools can detect a missing or empty page title. | Whether the title describes the page’s topic or purpose requires understanding the context of the page and its current state. |
| 4.1.2 Name, Role, Value (For content without custom widgets) |
Level A | Tools can detect controls with missing accessible names or roles. | Whether custom widgets expose the correct names, roles, and states to assistive technology when combined in a real-life environment, such as a process or user flow. |
Because accessibility checks against these criteria are fast and repeatable, they’re ideal for automated testing at scale and in every build. An accessibility checker can also roll results into an accessibility score, which helps you track your site’s accessibility over time. Keep in mind that an accessibility score summarizes rule results. A high accessibility score doesn’t confirm WCAG conformance. It helps to choose an accessibility checker that maps each rule to a success criterion.
Criteria where AI can provide directional input and people decide
For many criteria, automation and AI can tell you whether something exists, or whether it might be a problem. A person still needs to make the final call. The table below provides examples of criteria in this category.
| Criterion | Level | Where AI and automation help | What needs human validation |
|---|---|---|---|
| 1.1.1 Non-text Content | Level A | Tools can detect images with missing alternative text | Only a person who understands the context of the image on the page and why it was chosen can confirm that the alt text serves the same purpose, or that the image is decorative. |
| 1.2.2 Captions (Prerecorded) | Level A | Some tools can detect missing caption tracks. | Captions still need review for accuracy, speaker identification, and meaningful sound information. |
| 1.3.1 Info and Relationships | Level A | Tools can detect missing labels, table headers, and heading markup. | A user needs to confirm that markup reflects meaning, such as whether styled text is a true heading, related fields are grouped, and table headers are tied to the right data. |
| 2.4.4 Link Purpose (In Context) | Level A | Tools can detect empty links and flag ambiguous link text, such as “click here.” | People still need to judge whether each link’s text and surrounding context make its destination clear, including repeated links like “Read more” and image links that rely on alt text. |
| 2.4.6 Headings and Labels | Level AA | AI can suggest whether headings and labels seem descriptive. | Testers need to confirm that each heading describes the section it introduces and each label clearly states what to enter, using knowledge of the content AI doesn’t have. |
AI and automation make this middle group much faster to work through, because it can prioritize likely problems and explain them. It can’t confirm intent, which is where your team’s knowledge of the content comes in.
Criteria that depend on human judgment
Some criteria depend on meaning, order, and real use. Automation can flag candidates, and AI agents can move through a page with the Tab key or submit a form to trigger errors. But manual testing is needed to determine conformance. These criteria include the following.
| Criterion | Level | What only humans can decide |
|---|---|---|
| 1.3.2 Meaningful Sequence | Level A | Whether a mismatch between code order and layout changes meaning takes human judgment, since only sequences that affect understanding, like steps or instructions, fail this criterion. |
| 2.4.3 Focus Order | Level A | Walking through a page with a keyboard confirms whether focus moves in a logical order, including into and out of modals, menus, and newly revealed content. |
| 2.1.1 Keyboard | Level A | Whether every function across a complete journey supports keyboard access, using keyboard navigation alone. |
| 3.3.1 Error Identification (Level A) and 3.3.3 Error Suggestion | Level AA | Whether errors are identified and described in text that makes sense, and whether suggestions help users correct them. |
| 4.1.2 Name, Role, Value (When custom widgets are present) |
Level A | Testing custom widgets with screen readers confirms that roles match behavior and that names, states, and values update accurately as users interact. |
These are the criteria where screen reader users, keyboard users, and people with low vision are most likely to encounter accessibility barriers a scan can miss. Manual verification by experienced testers, including people with disabilities, closes that gap. You don’t need manual audits of every page. Focus manual testing on your key user flows, templates, and components, where one fix carries across your site.
How AI handles the new Level A and Level AA criteria in WCAG 2.2
WCAG 2.2 added six criteria at Levels A and AA. Automation’s coverage of them varies.
| Criterion | Level | Where AI and automation help | What needs human validation |
|---|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | Level AA | Tools can flag sticky headers, footers, and banners that may cover focused elements. | Hidden focus usually depends on combinations of zoom level, screen size, scroll position, and open banners or widgets, so a person needs to test those configurations. |
| 2.5.7 Dragging Movements | Level AA | Tools can flag drag-only controls like sliders and reorderable lists, suggest single-pointer alternatives such as “move up” and “move down” buttons, and simulate interaction flows. | AI may have trouble simulating dragging movements. |
| 2.5.8 Target Size (Minimum) | Level AA | Tools can measure target size and spacing against the 24 by 24 CSS pixel minimum. AI can also help decide whether an exception, such as a link inside a sentence, applies. | Non-AI automated testing can flag false positives. AI can help validate or dismiss these false positives, but people should check the issues AI dismisses don’t impact users. |
| 3.2.6 Consistent Help | Level A | Tools can check whether help mechanisms, such as contact links and chat widgets, stay in the same relative order across pages, review help content for clarity, and generate shared template code to fix inconsistencies. | A person still needs to confirm, with a screen reader and keyboard, that help mechanisms stay in a predictable order, including when modals, pop-ups, or other interactions change the page. |
| 3.3.7 Redundant Entry | Level A | Tools can walk through multi-step forms to flag repeated requests for the same information, then generate fixes like auto-populated fields or a “same as shipping address” checkbox. | Following a full process and tracking every field across steps adds complexity and cost for AI, so a person often validates the results. A person also decides whether an exception applies, such as re-entry being essential, required for security, or the earlier information no longer being valid. |
| 3.3.8 Accessible Authentication (Minimum) | Level AA | Tools can detect some patterns, such as blocked paste in password fields. | Whether a cognitive function test is required, and whether an alternative exists, takes human review. |
How properly skilled AI helps you fix and prevent issues
Accessibility testing tells you where your site stands. AI’s bigger contribution often comes next, in fixing the issues testing finds and preventing new ones in the first place. How well it does either depends on how it’s set up.
Fixing issues that testing finds
Once automated testing finds an issue, AI tools can help resolve it at the code level, directly in your source code. They can suggest specific fixes for missing accessible names, missing form labels, insufficient color contrast, and missing alt text. They can also group repeated accessibility issues that share a root cause, such as one component used across hundreds of pages. Remediating that component once can resolve every instance across your websites.
AI-suggested remediation still needs review. A fix that clears a scan can introduce a new problem, such as redundant or conflicting Accessible Rich Internet Applications (ARIA) attributes. Re-test every fix, and review changes to custom components with a screen reader and other assistive technologies.
Preventing issues in AI-written code
General-purpose AI assistants for coding don’t produce accessible code by default. In particular, they often reach for ARIA where native HTML elements would work better—and the WebAIM Million 2026 report names automated or AI-assisted coding practices among the likely factors driving an increase in ARIA-related errors.
That doesn’t mean AI can’t build accessibly. It means AI needs the right setup. AI can build experiences that meet most WCAG criteria from the start when it has:
- Accessibility guidance and skills built into the context it works from.
- Guardrails that favor native HTML elements over ARIA.
- An accessible design system with tested components to build from.
- Automated checks that give instant feedback as code is written.
- People who validate the result, especially for criteria that depend on human judgment.
The result is clean code and accessible websites from the first commit, rather than source code that needs remediation later. Every issue AI helps you prevent is one your team doesn’t have to find, prioritize, and fix later.
Reviewing AI-generated content
The same principle applies to content. AI tools can draft alt text, captions, transcripts, and summaries quickly. That output is content like any other, and your organization is responsible for its conformance with WCAG.
Generated alt text has to serve the same purpose as the image in context (1.1.1 Non-text Content). Generated captions have to accurately convey dialogue, speakers, and meaningful sounds (1.2.2 Captions (Prerecorded)). A person who knows the content should review AI-generated content before it’s published.
Applying WCAG to the AI features you ship
So far, we’ve covered how AI helps you test, fix, and prevent issues across your site. But what about the AI features you build into it? Under accessibility laws, an AI feature is generally held to the same technical standard as the rest of your site. That standard is typically WCAG.
AI assistants and chatbots are a common example, and they introduce dynamic content many teams haven’t tested before. To conform, a chat assistant needs to:
- Label the message input field (3.3.2 Labels or Instructions, Level A).
- Make the full conversation operable with a keyboard, including sending messages, reviewing earlier responses, and closing the assistant (2.1.1 Keyboard, Level A).
- Announce new and streamed responses to screen reader users through ARIA live regions, without moving keyboard focus (4.1.3 Status Messages, Level AA).
- Keep responses usable when text is resized to 200% and when content reflows at 320 CSS pixels wide (1.4.4 Resize Text and 1.4.10 Reflow, Level AA).
- Structure response formatting, such as headings, lists, code blocks, and tables, in markup rather than styling alone (1.3.1 Info and Relationships, Level A).
Streaming responses deserve special attention. If an assistant announces every fragment of a response as it arrives, screen reader output can become fragmented and hard to follow. Many teams program an assistant to announce when a response starts and finishes, then let users read the full text at their own pace. Testing with assistive tech, and with people with disabilities, is the most reliable way to confirm the experience works.
A practical workflow for WCAG 2.2 AA with AI in the loop
In a digital accessibility program, AI tools are most valuable when each one does the job it’s dependable at, and people handle the rest. Here’s a workflow that puts that into practice:
- Build with accessibility guardrails: Give the AI tools your teams use for design, content, and code your accessibility guidance, design system, and rules. This prevents many issues before they reach production.
- Scan your pages and components: Run automated testing in development, using real time scanning for instant feedback, and across your live websites.
- Group and prioritize the results: Combine repeated accessibility issues that share a root cause. Then rank high-impact issues by the user flows they affect.
- Fix issues with AI assistance: Use AI-suggested fixes at the code level, and have a developer review each one.
- Re-check in continuous integration (CI): Add automated checks to your build pipeline so fixed issues stay fixed.
- Manually evaluate what matters most: Have accessibility experts, including people with disabilities, audit your key user flows, templates, and components. Focus manual testing on the criteria that depend on human judgment.
- Record evidence and monitor: Use remediation tracking to document what you found, fixed, and verified for accessibility compliance reporting. Then set up ongoing monitoring so your site’s accessibility holds as new content is published.
Put AI to work where it’s dependable
Artificial intelligence can make WCAG conformance faster to reach and easier to maintain. Properly skilled AI helps you build accessible websites from the start, then find and fix issues at scale. Conformance still rests on full pages and complete processes, and human judgment closes the gap automation leaves.
Level Access is the accessibility layer for AI-enabled workflows. We bring together intelligent automation, connected workflows, and human expertise so your teams can identify risk, resolve accessibility issues in-flow, and ship with confidence. Request a demo to learn how.
The post Can AI Make a Website WCAG Conformant? A Comprehensive Guide appeared first on Level Access.