Audit an AI-Generated Website for Accessibility

Use an automated scan to find possible failures, then test the actual tasks by hand. A generated page can have valid-looking markup yet trap keyboard users, hide focus, or give a form field no useful name. The output of this audit is an issue ledger with a reproduction step, a fix, and a retest result. It is not a certificate of WCAG conformance. W3C says that some accessibility checks cannot be automated.

This guide applies to the generated site you can edit and test. It does not assess another platform's editor or grant an AI tool access to that platform. Test a representative page for each distinct template, plus every unique interaction such as a menu, form, dialog, or carousel. Test both desktop and narrow layouts because a mobile menu can fail even when desktop navigation works.

What goes into the issue ledger?

Use columns for page and viewport, task, expected behavior, observed behavior, severity, source or criterion, fix owner, and retest evidence. Do not write only "accessibility score: 90." A score cannot tell a developer which action fails or show that a user can complete it.

This illustrative example shows how to document a finding. It is not a first-hand result from a live Figment site.

The label repair follows W3C's form-label tutorial. Do not replace a visible label with input hint text. That text can vanish when a person types and can be hard to read. For a menu, prefer native button and link elements before adding ARIA to a non-interactive div.

How do I test without a mouse?

Start at the address bar and move through the page with Tab and Shift+Tab. Confirm that focus follows a sensible order and remains visible. Use Enter or Space to activate controls as appropriate. Open and close menus and dialogs; confirm that focus does not disappear behind an overlay and that you can leave every control. Repeat on the mobile layout. W3C's preliminary checks give a practical keyboard sequence and warn about keyboard traps.

Check skip navigation if repeated headers make a long route. Check that a fixed header does not cover the focused item. WCAG 2.2 adds a focus-not-obscured requirement. A change that merely adds a bright outline is insufficient if the active control is hidden under a sticky bar.

Which visual and semantic checks matter?

Read the page in order with CSS and images considered separately. Check one descriptive main heading, meaningful heading levels, lists that are real lists, and link text that makes sense outside its paragraph. Give informative images useful alternative text. Give decorative images empty alternative text. Do not trust AI-generated alt text without comparing it with the image and its purpose.

Measure text contrast in real states: normal, hover, focus, disabled where relevant, and text placed over images. WCAG's contrast guidance sets a 4.5:1 minimum for ordinary text at Level AA and 3:1 for qualifying large text. Check actual foreground and background colors; a screenshot's appearance alone is not a measurement. Also check non-text controls and focus visibility against the applicable WCAG criteria. Do not remove the browser's default focus indicator unless the replacement is clear.

For forms, use visible labels, clear required-field instructions, useful error text, and a success state that users can perceive. Submit an empty form, an invalid value, and a valid value. A visually convincing form that never sends is a functional defect as well as a possible accessibility defect. The separate form implementation guide owns delivery and abuse controls.

Use a screen reader on the flows that matter most: navigation, headings, form entry, error recovery, and confirmation. Listen for the control name, role, state, and order. Record which browser and screen reader you used. Ask people who use assistive technology for review when the site has consequential tasks; an agent's scan cannot substitute for that experience.

When is the audit complete?

Run an automated checker on each template after manual repairs. Save its report as one input to the ledger, not a pass badge. Reproduce and retest every high-impact issue on the deployed build. Mark unresolved barriers explicitly and hold launch when a core task cannot be completed with the keyboard or assistive technology. A final review still needs to cover content changes after this test. Use the launch acceptance checklist to record that decision.

You can prepare a precise repair prompt from the ledger. Review the resulting code or page yourself. Figment's AI editor remains access-gated, and its separate static copy is not an automatic repair of the original hosted site.

Sources and access date

W3C's evaluation tool overview, preliminary checks, form-label tutorial, and WCAG 2.2 changes were accessed 2026-09-23.