Make an AI-generated website more accessible

Include content changes in the review. A new photograph can reduce caption contrast, a longer translated label can clip a button, and a newly added field can disturb the tab order. Accessibility work is therefore part of ordinary publishing, not only a final technical audit. Keep the important task checks with the project's release notes and repeat them whenever content or shared components change.

Accessibility is easier to review when you begin with a real journey: find a service, navigate to a project, send an inquiry, or save a personal record. A website can look elegant while blocking that task for someone using a keyboard, screen reader, magnification, or reduced-motion setting. Describe the important journey in your brief and test it through more than one input method. The objective is useful access to the same outcome.

AI generation does not remove the need for human review. Automated checks can identify some problems, but they cannot decide whether an image description is meaningful, whether navigation labels make sense, or whether a complex task is understandable. Treat the W3C's current WCAG guidance as a reference for your review. Do not turn a passing automated score into a blanket claim that the entire website is accessible or compliant in every context.

Use headings to describe the content hierarchy, not merely to obtain a larger font. A page needs a clear main heading, logical section headings, and landmarks that distinguish navigation, main content, and supporting information. Link text should make its destination understandable. Repeated ‘learn more’ labels can be ambiguous when read outside their visual context; a label such as ‘View the Willow Road project’ gives the destination a useful name.

Choose native elements for their behavior. A link moves to a destination; a button performs an action. Replacing either with a clickable generic container can lose keyboard support and semantics. Ask the builder to preserve these relationships when restyling. If a visual order changes on a phone, check the underlying reading and focus order as well. A screen reader or keyboard user should not have to follow a sequence that contradicts the visible page.

Set the pointer aside and use Tab, Shift+Tab, Enter, Space, arrow keys where appropriate, and Escape. The focus indicator should remain visible on every interactive control. The order should follow the task, without jumping unexpectedly between columns or disappearing behind a fixed header. Make sure all main actions can be reached and activated. A control that responds to a mouse click but never receives keyboard focus is a real functional defect.

Menus and dialogs need special attention. Opening a dialog should place focus somewhere sensible inside it, keep interaction within the active dialog, and return focus to the opener after closing. Escape should close a dismissible overlay. A phone menu must have a reachable close action even on a short viewport or with enlarged text. Do not trap visitors inside a component, and do not let an invisible overlay intercept clicks after it appears to close.

Readable text depends on the foreground and the background it actually appears on. A light caption over a photograph may pass in one crop and disappear in another. Secondary text, placeholders, disabled controls, and validation messages need deliberate review, not only the largest headline. WCAG's common minimum contrast requirements include 4.5 to one for ordinary text and three to one for large text, with the relevant definitions and exceptions in the standard.

Do not use color as the only way to communicate a state. An error needs text or another clear indicator; a chart needs distinguishable labels or patterns; a selected filter should remain recognizable beyond a subtle hue change. Preserve the project's visual identity while adjusting the combinations that fail. If an orange button cannot support a readable label in its current shade, changing the shade or text treatment is a precise design correction rather than a reason to abandon the palette.

Every field needs a persistent accessible label. A placeholder disappears when the visitor types and should not be the only description. Explain required formats before submission where useful, and associate instructions and errors with the relevant input. Use appropriate input types and autocomplete values for common personal information. A clear label and a helpful error often improve the form more than decorative containers or elaborate animations around each field.

Test the entire form lifecycle: empty submission, invalid values, pending request, success, and failure. Keep safe input after a recoverable error. Make status changes available to assistive technology without unexpectedly moving focus or repeatedly announcing the whole page. A form must also have a real destination; accessible fields attached to a fake submit action still fail the visitor. For connected collection or private records, test the actual service outcome as well as the visible confirmation.

An image description should explain the information the image contributes in this context. A project photograph may need a concise description of the space; a decorative texture may need an empty alternative so it does not interrupt reading. Avoid repeating a nearby caption verbatim when it adds no information. For a linked image, consider the destination as well as the picture. The right text depends on the role, not on a generic formula applied to every asset.

For audio and video, provide appropriate alternatives such as captions and transcripts when the content carries information. Do not make audio start unexpectedly, and give visitors clear playback controls. A background film should not be the only place essential instructions appear. For a canvas game or chart, put meaningful instructions and important status in ordinary document content where possible. Pixels can be an effective presentation, but they should not become an unexplained barrier to the surrounding task.

Review the page with enlarged text and browser zoom. Content should reflow where appropriate rather than requiring horizontal scrolling to read ordinary paragraphs or reach the main action. Check long names, expanded accordions, and form errors; these states often reveal layout assumptions that a short sample does not. Tables may need a clearly usable scrolling region, but the whole page should not overflow because one cell contains a long string.

Respect reduced-motion preferences by removing or reducing decorative movement, parallax, and unnecessary transitions. Keep content visible if animation does not run. Provide pause for moving content when appropriate. For a game, distinguish essential gameplay movement from decorative shake and flashes; reduced motion should not silently make the game impossible to start. Test real settings rather than assuming that a CSS rule covers every animation library, canvas effect, or timed interaction in the project.

Use automated accessibility tools to find mechanical issues, then inspect the rendered page and complete its main task manually. A useful review record names the route, state, issue, expected behavior, and the way you tested it. Prioritize blockers such as unreachable navigation, missing form labels, invisible focus, and unreadable text. After a correction, repeat the task and check adjacent behavior. A visual edit can fix contrast while accidentally removing a button's semantics.

Ask for feedback from people who use different access methods when the project scope allows it. Document remaining issues honestly and avoid publishing a compliance claim you have not established. Accessibility remains part of maintenance: new content, longer translations, a different hero photograph, or a changed menu can introduce new problems. Keep the review checklist with your release process so improvements survive later AI revisions and the exported site's deployment.