AI coding tools can speed up an initial website build, but businesses should not publish their output without accessibility testing. Recent testing reported that 15 websites produced by several AI coding tools failed to meet the most basic accessibility level, so human review remains necessary.
The practical lesson is simple. Use AI to create a draft, then test the finished pages with automated tools, keyboard navigation, and assistive technology before visitors depend on them.
What the recent testing found
A report summarized by an established news publication examined websites created from prompts requiring compliance with Web Content Accessibility Guidelines 2.2 Level AA. The test covered a news site, an online store, and a financial services site for each of five AI coding tools.
None of the 15 tested sites met Level A, the first and most basic WCAG conformance level. The testing identified 306 distinct accessibility issues, which appeared more than 59,000 times across the pages.
Those results do not prove that every AI-generated website has the same problems. They do show why a prompt requesting accessible code is not a substitute for testing the actual pages, forms, navigation, and interactions.
Why an accessibility prompt is not enough
AI tools generate code from patterns and instructions, but they do not automatically understand every visitor's experience. A page can look correct while still hiding important information from keyboard users or people who use screen readers.
Accessibility also depends on the content added after the first draft. Staff may upload images without descriptions, change colors, remove visible labels, or add a form that lacks clear instructions.
That means accessibility belongs in the website's normal publishing process. Every new page, feature, form, and template needs a short review before it reaches customers.
Start with these seven checks
- Keyboard access. Use the Tab, Shift plus Tab, Enter, and arrow keys to operate the page without a mouse. Every link, button, menu, dialog, and form control should be reachable in a sensible order.
- Visible focus. Confirm that the active link or control has a clear visual indicator. If visitors cannot see where the keyboard focus is, they can lose their place quickly.
- Form labels. Check that every field has a visible, specific label. Placeholder text should not be the only instruction because it can disappear when someone starts typing.
- Heading structure. Review headings for a logical order that describes the page. Headings should organize the content rather than serve only as large decorative text.
- Image descriptions. Add useful alternative text to meaningful images and mark decorative images appropriately. The description should explain the image's purpose on that page.
- Color and contrast. Check text, controls, links, and status messages for sufficient contrast. Do not use color as the only way to communicate an error, change, or required action.
- Links and buttons. Make each control's purpose clear from its text or accessible name. Avoid vague labels such as "click here" when the surrounding context does not explain the destination.
Combine automated and manual testing
Automated accessibility checkers can find repeated issues efficiently. They can flag missing labels, absent image descriptions, some contrast failures, invalid markup, and other problems that deserve correction.
Automation cannot judge every meaningful experience. A tool may confirm that a label exists without telling you whether the label makes sense, and it may miss a confusing focus order or an unusable dialog.
After an automated scan, test important tasks manually. Open the navigation, complete a form, review an error message, select an item, and reach the final confirmation using only a keyboard.
Then test those tasks with a screen reader where possible. Listen for page titles, headings, form labels, button names, error messages, and confirmation text. Record each failure with the page address, affected control, and recommended fix.
Test the tasks that affect revenue
Small businesses should begin with the actions that matter most to customers. Prioritize contact forms, appointment requests, account access, purchases, quote requests, newsletter signups, and any other path that produces a lead or sale.
For each task, write a short test script. For example, a reviewer might open the page, find the form, enter valid information, trigger an error, correct the field, submit the form, and confirm the result.
Run the script with a keyboard first. Then repeat it with a screen reader and on a small screen. This approach finds practical barriers faster than reviewing a long list of technical findings without considering customer goals.
Fix the source, not only the appearance
When a page fails, correct the underlying HTML, CSS, JavaScript, or content. A missing form label needs a proper label, and a weak focus indicator needs a visible focus style that remains available through the entire interaction.
Temporary visual patches may hide a problem without making the page understandable to assistive technology. After each correction, rerun the automated scan and repeat the manual task that exposed the issue.
Keep a simple record of findings, owners, dates, and verification results. The record helps the team prevent the same error when it creates another page or changes a shared template.
Set a publishing rule for AI-generated code
Before publishing an AI-assisted website change, require four approvals: content review, functional testing, accessibility testing, and security review. The reviewer should verify both the generated code and the final content entered by staff.
Ask the person using the tool to describe what was generated and what was changed afterward. That information makes later maintenance easier and helps another reviewer find areas that need closer attention.
Keep AI-generated code in the same review process as hand-written code. Test it in a nonpublic environment, check forms and integrations, and publish only after the required checks pass.
A practical next step
Choose one important page and complete the seven checks above. Fix the highest-impact barriers first, then apply the same checklist to shared templates before adding more AI-generated pages.
AI tools can reduce drafting time, but accessibility remains a website responsibility. A tested page gives customers a clearer path and gives the business a repeatable standard for future changes.
Sources
- Study: AI coding tools do not write accessible code
- Website accessibility lawsuits are rising, and smaller businesses are frequent targets
- seroundtable.com
- developers.google.com
- blog.google
- loop-digital.co.uk
Want a second pair of eyes on this for your own site? Start with a message: send us your site address and your question. If talking it through will help, book the free 60-minute phone or Zoom consultation, which covers a look at your current website and online presence, your goals, and a written action plan with next steps sent afterward.
Tags
Frequently Asked Questions
Can AI coding tools create an accessible website?
They can help produce a starting point, but generated code still requires automated checks, keyboard testing, screen reader testing, and human review.
What should a business test first?
Start with keyboard access, form labels, heading structure, image descriptions, color contrast, focus indicators, and meaningful link text.
Should accessibility overlays replace code fixes?
No. Fix accessibility problems in the website code and content, then retest after updates instead of relying only on an overlay.
Enjoyed this article?
Share it with your network









