AI output accessibility checker
AI models are good at producing markup that renders and bad at producing markup
that works for everyone. The classic tells: a <div onClick> pretending to be a
button, an <img> with no alt, an <input> with no label, and color choices
that look fine to the author but fail contrast for low-vision users. This checker
parses AI-generated HTML and copy and flags those issues against WCAG 2.1 AA
expectations, with the exact element and a fix for each.
How it works
You paste the HTML or component markup. The tool runs a set of detectors:
images without alt, clickable div/span without a button role or tabindex,
form controls without an associated label, generic markup where a semantic
element belongs, missing language attribute, and links with non-descriptive text
(“click here”). If you also supply a foreground and background hex color, it
computes the WCAG contrast ratio and checks it against the 4.5:1 (normal) and
3:1 (large) thresholds. Each finding cites the relevant criterion. Everything
runs locally in the browser.
Tips and limits
- Automated checks are a floor, not a ceiling. They find roughly a third of real issues. Always follow with keyboard-only navigation and a screen reader.
- Fix semantics first. Replacing
<div onClick>with a real<button>fixes focus, keyboard, and role in one move — far better than bolting on ARIA. - Alt text should describe purpose. Decorative images get
alt=""; meaningful ones get a concise description of what they convey, not the filename. - Re-check after edits. Accessibility regressions are easy to reintroduce on the next AI-assisted change, so make this part of your review loop.
Why AI-generated code is particularly prone to accessibility gaps
AI coding assistants are trained to produce code that compiles and renders correctly — criteria that have nothing to do with screen reader behaviour, keyboard operability, or WCAG conformance. The training data for code generation includes enormous amounts of web content that itself has accessibility problems, which the model treats as valid patterns.
The practical result: AI-generated UI code tends to get the visual appearance right while systematically skipping the parts that are invisible on screen but essential for users of assistive technology. Some patterns that appear repeatedly:
- Interactive divs and spans — a
<div>with anonClickhandler looks and behaves like a button in a mouse-based demo, but receives no keyboard focus, has no implicit ARIA role, and is invisible to a screen reader. - Images with no alt attribute — AI generates
<img src="...">regularly without analtattribute. Screen readers may read the filename aloud, which is useless or worse. - Form controls detached from labels — generated forms often place a
<label>and an<input>near each other in markup without linking them withfor/id, so clicking the label does not focus the field and screen readers do not announce what the field is. - Color choices outside contrast thresholds — AI models pick color pairs that look harmonious on a calibrated display but fail the 4.5:1 contrast ratio that WCAG 2.1 AA requires for normal text, affecting users with low vision.
What the checks cover
| Check | What is flagged |
|---|---|
| Images | <img> elements missing an alt attribute |
| Interactive elements | <div> or <span> with click handlers but no button role or tabindex |
| Form labels | <input>, <select>, <textarea> without an associated <label> |
| Language attribute | Missing lang on the root <html> element |
| Link text | Links with non-descriptive text such as “click here” or “read more” |
| Contrast (optional) | Foreground/background hex pairs checked against the 4.5:1 and 3:1 thresholds |
These are the issues that automated analysis reliably detects. They are also the issues AI generators most commonly introduce, so this check is well-targeted to the specific failure mode of AI-assisted frontend work.
Practical workflow
A useful pattern for teams using AI code assistance is to paste each generated component through this checker immediately after generation and before peer review. Fixing accessibility issues at that point costs seconds; finding them after a component is wired into a production app costs hours. The checker also makes a useful filter in code review — a screenshot of the zero-findings output is a quick confirmation that the obvious automated checks passed, leaving the human reviewer to focus on semantic correctness and keyboard flows.