How AI Generates Production-Ready WCAG Code Fixes (And Where It Falls Short)

When a scanner flags a missing alt attribute, anyone can write the fix. The interesting question is: can an AI write a useful alt attribute — one that describes what the image actually shows in context, not just “image” or a filename?

The answer, in 2026, is: mostly yes, with important caveats. This article walks through the actual workflow Certvo uses — rule detection, LLM prompt construction, code generation, confidence scoring — and then explains honestly where AI-generated fixes still fall short and why human review is not optional.

The Workflow: Rule → Prompt → Code → Confidence

Most accessibility scanners work by running a set of deterministic rules against the DOM. Rule 1.1.1 says: every <img> must have an alt attribute that is not empty (unless the image is decorative). If an image fails, the scanner emits a violation object with metadata about the element.

For an AI-powered scanner, that violation object becomes the input to a prompt. The prompt is constructed to include:

• The WCAG success criterion being violated
• The offending HTML element and its surrounding context (parent elements, sibling text, page title)
• For images: a base64-encoded version of the image (if accessible via the page's origin)
• The type of fix expected (e.g., add alt attribute, change role, wrap in a label element)

The LLM — Certvo uses Claude — returns a structured fix including the corrected HTML and a confidence score (0–100). Below confidence 70, the fix is flagged for human review. Above 90, it is presented as a ready-to-apply patch.

Worked Example 1: Missing Alt Text

Input HTML:

<div class="product-card">
  <img src="/products/blue-backpack-32l.jpg" />
  <h3>TrailPro 32L Backpack</h3>
  <p>$89.99</p>
</div>

The AI sees the image URL, the product name from the sibling heading, and — if cross-origin policy permits — the actual image. It generates:

<div class="product-card">
  <img
    src="/products/blue-backpack-32l.jpg"
    alt="TrailPro 32L Backpack in navy blue, shown from the front with padded shoulder straps"
  />
  <h3>TrailPro 32L Backpack</h3>
  <p>$89.99</p>
</div>

Confidence: 91. The heading text “TrailPro 32L Backpack” gives strong context. The image URL filename (“blue-backpack-32l”) is used to infer color and type. If the image could be loaded, the description of the front-facing angle comes from visual analysis.

Worked Example 2: Color Contrast Failure

Input CSS:

/* Computed values from scanner */
.cta-button {
  color: #6b7280;       /* gray-500 */
  background-color: #f3f4f6;  /* gray-100 */
  /* Contrast ratio: 2.7:1 — fails WCAG 1.4.3 AA (needs 4.5:1) */
}

AI fix (adjusts foreground to meet 4.5:1 while staying on-brand):

.cta-button {
  color: #374151;       /* gray-700 — 7.0:1 contrast ratio */
  background-color: #f3f4f6;
  /* ✅ Passes WCAG 1.4.3 AA and AAA */
}

Confidence: 88. The AI knows the contrast formula and can explore adjacent values in the same color family to find a compliant option. The remaining uncertainty (88 vs 95+) is because it does not know whether the brand guidelines specify exact gray values — a human designer should confirm the color choice fits the design system.

Worked Example 3: ARIA Misuse

This is where it gets interesting. ARIA is powerful but has a strict role model — applying the wrong role, or applying role="button" without the corresponding keyboard behavior, creates worse accessibility than no ARIA at all.

Input:

<div
  class="dropdown-trigger"
  role="button"
  onclick="toggleDropdown()"
>
  Menu ▼
</div>

Problem: role="button" is set but there is no keyboard handler, no tabIndex, and no aria-expanded to signal dropdown state. Screen reader users will find a “button” that does nothing when activated via keyboard.

AI fix:

<button
  class="dropdown-trigger"
  aria-expanded="false"
  aria-haspopup="true"
  aria-controls="dropdown-menu"
  onclick="toggleDropdown(this)"
>
  Menu ▼
</button>

<!-- In your JS, also update aria-expanded dynamically: -->
function toggleDropdown(el) {
  const expanded = el.getAttribute('aria-expanded') === 'true';
  el.setAttribute('aria-expanded', String(!expanded));
  // ... rest of toggle logic
}

Confidence: 82. The AI correctly replaces the div with a semantic <button>, adds the right ARIA attributes, and shows the JavaScript update needed. The lower confidence score reflects that the fix requires a JS change as well as an HTML change — the AI cannot verify that the JS function will be updated consistently.

Where AI Falls Short

Being honest about limitations matters here:

Logic-Heavy Complex Components

A multi-step form wizard with conditional fields, a drag-and-drop interface, or a live-updating data grid with sortable columns — these require accessibility implementations that depend heavily on application state. AI can suggest the right ARIA patterns, but wiring them up correctly requires understanding the application's state management. Human review is mandatory.

Novel or Unusual Components

Custom components that do not map cleanly to existing ARIA roles — an interactive map, a custom date picker, a timeline scrubber — require the developer to make judgment calls about which ARIA design pattern to follow. AI can point to the right ARIA Authoring Practices Guide pattern, but applying it correctly requires development work.

Alt Text for Context-Dependent Images

An image of a chart requires alt text that summarizes the data — not a description of the visual. An image of a person requires alt text that varies depending on whether the person is being identified or is decorative. AI handles product photos and diagrams well but struggles with images whose meaning depends on editorial context the AI cannot access.

Human Auditor vs. AI: The Actual Numbers

A professional accessibility auditor testing a single page manually takes about 2 hours for a thorough review — checking assistive technology behavior, testing on-device, verifying edge cases. An AI scanner completes the same page in under 30 seconds. But the AI catches roughly 30-50% of what the human would catch. The right approach is AI-first: use automated scanning to eliminate the easy failures quickly and cheaply, then focus human testing time on interaction-heavy pages, custom components, and content-type edge cases.

Certvo's Approach

Certvo uses Claude for code fix generation because its instruction-following capabilities produce more consistent, context-aware fixes than alternatives we tested. The integration works through the MCP API — which means you can also trigger Certvo scans and fix generation directly from Claude or any MCP-compatible agent. Fixes are returned as diffs you can review and apply; nothing is auto-merged without your confirmation.

Ready to see what AI can catch on your site? Run a free scan and review the AI-generated fixes. You can apply what looks good and flag what needs human review.