What Accessibility Checks Are Needed for an AI-Generated Website?

Short answer: Treat AI-generated code as a starting point, not an accessibility test result. A useful review combines automated checks with a human inspection of semantic structure, keyboard operation, focus behavior, labels, contrast, alternative text, motion, zoom and responsive layouts, followed by representative assistive-technology testing. Use a named standard and version—such as WCAG 2.2—as the scope for your review, document what you tested, and avoid claiming that a site works for every person or satisfies every applicable rule.

WCAG 2.2 describes accessibility through four principles—perceivable, operable, understandable and robust—and provides testable success criteria alongside techniques and explanatory material.[1] Those criteria are valuable anchors for an AI-assisted build, but W3C also explains that even the highest conformance level cannot address every combination of disability. [2]

Set the review scope before opening a checker

Record the website version, URLs or templates included, browsers and viewport sizes, language, interactive states, content types, and the WCAG version and conformance level you intend to examine. A small brochure site may need a representative sample of pages; a product with accounts, checkout, search, dialogs and error states needs those flows tested as well. WCAG-EM 2.0 recommends a structured evaluation process that defines the evaluation scope, explores the site, identifies a representative sample, audits it and reports the findings.[3]

This is a technical quality workflow, not a legal opinion. Accessibility duties and technical expectations can vary by jurisdiction, sector, audience, procurement context and time. If the site is connected to a regulated service, public program, employment process or contractual requirement, ask an appropriately qualified accessibility specialist and review current primary rules.

The human-led accessibility checklist

1. Inspect semantic structure and reading order

Check that each page has one meaningful title, a logical heading hierarchy, landmarks where useful, lists marked as lists, tables marked as tables, and links whose text makes sense out of context. Prefer native HTML elements—such as button, nav, label and main—before adding ARIA. AI often produces visually convincing div-based controls or headings selected for appearance rather than meaning.

Review the DOM and, where possible, navigate the page with styles disabled or by inspecting the accessibility tree. Ask whether the order in the source and accessibility tree matches the intended task: introduction, choices, content, form, confirmation. A visual layout that looks correct can still become confusing when read sequentially.

2. Operate every function with a keyboard

Unplug the mouse for a complete pass. Tab through links, buttons, menus, dialogs, carousels, accordions, date pickers and custom widgets. Enter activates the expected control; arrow keys or Escape behave consistently where the component requires them; and no action depends only on hover, dragging or a precise pointer gesture. Confirm that keyboard users can reach, use and leave every interactive element without becoming trapped.

Pay special attention to AI-created components that imitate native controls. A clickable card, icon or span is not automatically a usable button. If a custom widget is unavoidable, test its name, role, value, state and keyboard instructions in the browser’s accessibility tree and with a screen reader.

3. Check focus visibility, order and dialog behavior

Keep a visible focus indicator and verify that it is not hidden behind sticky headers, clipped by containers or removed by a global CSS reset. Follow focus as the page changes. When a dialog opens, focus should move to an appropriate control, remain inside while the dialog is active, and return sensibly when it closes. For a single-page application, check route changes, loading states and toast messages rather than testing only the initial render.

Record the exact state and reproduction steps for each failure. “Focus is broken” is less useful than “After selecting Filter, focus moves to the page footer and the dialog has no accessible name.”

4. Review names, instructions and errors in forms

Every input needs a programmatically associated label or an equivalent accessible name. Instructions should not exist only as placeholder text. Check required fields, format guidance, autocomplete behavior, grouped radio buttons and checkboxes, and error messages. Submit incomplete and invalid forms with the keyboard, then verify that errors are announced or otherwise discoverable, the affected fields are identified, and the user can recover without losing already entered information.

Test success and failure—not just the happy path. AI-generated validation frequently checks a value visually but fails to expose the state to assistive technology, or displays an error beside a field without connecting the two.

5. Verify contrast, color and non-text indicators

Use a contrast analyzer as a screening step, then inspect real states: default, hover, focus, disabled, selected, visited and error. Do not communicate meaning through color alone. Check charts, badges, borders, icons and status messages, including content over images or gradients. The applicable threshold depends on the WCAG success criterion, text size, graphical object and state, so report the criterion and measured context rather than a vague “passes contrast.”

Also test high zoom and text enlargement. A page can have acceptable color contrast yet become unusable when text reflows, controls overlap or content disappears.

6. Check images, media and generated content

For each informative image, write concise alternative text that conveys its purpose in context. Mark decorative images appropriately and avoid repeating adjacent visible text. An AI-generated caption may describe what is pictured while missing why the image is present; a human should decide whether the text is accurate, useful and current.

Review video captions, audio alternatives, transcripts, autoplay, flashing content and animated transitions. Provide controls for nonessential motion and respect a user’s reduced-motion preference where appropriate. Do not use a stock “accessible” label as a substitute for checking the actual media and controls.

7. Test zoom, reflow, mobile input and orientation

Resize the viewport and use browser zoom and text-only enlargement. Look for horizontal scrolling that forces two-dimensional navigation, clipped menus, inaccessible off-canvas panels, fixed elements covering content, and touch targets that are difficult to distinguish. Test portrait and landscape where the product supports both. WCAG 2.2 is designed for web content across device types, but the behavior of the browser, operating system and assistive technology is also part of the user experience.[4]

8. Run automated checks, then verify the findings manually

Use more than one automated signal if practical: a browser audit, an accessibility scanner and HTML or CSS validation can expose different issues. W3C’s evaluation overview explicitly states that knowledgeable human evaluation is needed to determine whether a site is accessible, and that tools cannot check everything.[5] Treat a clean report as evidence about the rules the tool checked, not as a universal pass.

Manually confirm every flagged item. Tools can report false positives, miss context, or fail to understand whether alternative text, link wording, heading order or an error message actually serves the user’s task. Conversely, they may not detect a keyboard trap, confusing instructions or a broken screen-reader announcement.

A repeatable review workflow

1. Inventory: list templates, routes, components, content types and critical journeys.
2. Baseline: note the browser, operating system, assistive technology, viewport, zoom and build revision.
3. Screen: run automated tests and sort findings by user impact and frequency.
4. Explore: complete the keyboard, focus, form, zoom, media and content checks above.
5. Assistive technology: test representative journeys with a screen reader and, where relevant, magnification, voice input or switch access. Include people with disabilities in research or usability testing when you can do so appropriately.
6. Fix and regress: correct the underlying component or content pattern, rerun the journey, and retain evidence of the result.
7. Report: state the scope, standard/version, tested sample, known limitations, open issues, owner and next review date.

Original decision tool: the four-question release gate

Before handing off an AI-assisted site, answer each question with Yes, No or Not tested. “Not tested” is not a pass.

• Structure: Can a person understand the page and its order using headings, landmarks and native controls?
• Operation: Can a person complete every important journey with a keyboard, visible focus and no trap?
• Communication: Are names, instructions, states, errors, alternatives and status changes available in the relevant modality?
• Resilience: Does the experience remain usable across the selected browsers, zoom levels, viewport sizes and assistive technologies?

If any answer is No, fix or explicitly document the issue before release. If any answer is Not tested, narrow the claim to the tested scope and schedule the missing check. This gate does not certify compliance or universal accessibility; it creates a transparent boundary around what the team actually reviewed.

What AI can and cannot do in this process

AI can help explain an error, generate a test matrix, identify repeated component patterns, suggest semantic HTML and produce draft alternative text. It can also repeat a mistake consistently across every page. A human must inspect context, content accuracy, interaction behavior and the lived task, then decide whether the proposed fix is appropriate. Keep the generated code reviewable, pin the tested revision and avoid silently replacing accessible hand-written components with generated equivalents.

The strongest deliverable is therefore not a badge or a blanket statement. It is a dated report that says what was examined, which WCAG version and criteria were used, which journeys worked, which issues remain, and what should be retested after the next code or content change.

Sources and further reading

1. W3C, Web Content Accessibility Guidelines (WCAG) 2.2 Recommendation.
2. W3C, WCAG 2.2 Conformance Requirements and Limitations.
3. W3C, Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 2.0.
4. W3C, WCAG 2.2 Introduction: Layers of Guidance and Device Context.
5. W3C WAI, Evaluating Web Accessibility.

Editorial note: This article is educational information, not legal, tax, financial, privacy, copyright or compliance advice. Standards, rules and product behavior can change; use the current primary materials and qualified professional review for decisions that require it.