Accessibility Scanner
5 min read
Run an accessibility scan to check your project for WCAG issues before publishing.
Who can do this: Owners, Admins, and Editors can run accessibility scans before publishing; anyone with build permission on the project. See Roles and Permissions for details.
Run an accessibility scan before you publish. The scanner checks your project code against WCAG 2.2 Level A/AA patterns, looking for issues like missing alt text, form labels, keyboard accessibility, and semantic structure. You get a report grouped by severity, and you can fix issues one-by-one or all at once with AI.
Where to Find It
You can start an accessibility scan two ways:
From chat. Ask things like “check accessibility,” “run an a11y scan,” or “check for screen reader issues.” The agent runs the scan and shows results in the conversation.
From publish. Click Publish → Review readiness → Accessibility row → Run scan. The scan takes about two minutes.
What Gets Checked
The scanner combines two layers of analysis:
Automated linting. Runs 31 jsx-a11y rules across every .tsx and .jsx file in the src/ directory of your project. This catches structural issues like missing alt text, invalid ARIA attributes, unlabeled form inputs, and click handlers on non-interactive elements.
AI-assisted checks. Reviews 21 additional patterns the linter cannot infer from individual components:
- Missing
<html lang>attribute - Viewport zoom restrictions
- Autoplay media without controls
- Missing
prefers-reduced-motionhandling - Focus outline removal without replacement
- Low-contrast Tailwind class candidates
- Interactive elements smaller than 24×24 pixels
- Heading structure (single
<h1>per page) - Landmark presence and duplication
- Drag-only interactions without keyboard alternatives
- Vague link text (“click here,” “read more”)
- Sub-16px input fields (triggers iOS zoom)
- Table caption and header structure
- Skip-link targets
- Third-party accessibility overlay widgets (AccessiBe, UserWay, etc.)
- Form error announcement wiring
Running a Scan
Initial scan. Ask the agent to check accessibility, or click Run scan in the publish readiness step. The scan runs immediately with no approval needed.
Post-fix scan. After the agent applies fixes, it shows a re-audit approval card. Click Run audit to verify the fixes worked. You control when the re-scan runs.
While scanning, you see a compact card in chat with a spinner. When complete, a summary card shows what was found.
Understanding Results
After a scan, you see severity counts:
| Severity | What it means | Examples |
|---|---|---|
| Critical | Issues that could block users entirely. Fix before publishing. | Missing alt text, unlabeled inputs, invalid ARIA, tiny tap targets, accessibility overlays |
| Warning | Best practice violations worth addressing. | Focus outline removed, vague link text, duplicate landmarks, drag-only interactions |
| Info | Minor recommendations and positive signals. | Low-contrast class candidates, missing autocomplete, use of contrast-color() |
If everything passes, you’ll see “No accessibility issues found” with a green checkmark.
Viewing the Full Report
Click the summary card to open the full report panel. Each finding shows:
- Human-readable title describing the issue
- Rule ID and file location (
path:line) or occurrence count - Expandable drawer with every affected file and line
- Fix with AI button for targeted fixes
Fixing Issues
Fix one issue. Expand a finding and click Fix with AI. The agent then sends a fix request to the chat and starts applying changes.
Fix all issues. Click Fix N issues on the summary card to address all critical and warning items at once. Info-level findings are not included in “Fix all.”
After fixing. The agent prompts you to re-run the scan. Click Run audit on the approval card to confirm the issues are resolved. Fixes do not auto-resolve. The scan is the source of truth.
Scan Status in Publish Flow
The Accessibility row in the publish readiness step shows where your scan stands, not what it found:
| Status | What it means |
|---|---|
| Not run · ~2 min | No scan has been run yet |
| Running… | A scan is in progress |
| Last run <time> | When your most recent scan finished. The button switches to Rerun scan. |
| No code changes since last scan | Your last scan is still current. Nothing has changed in the project since it ran. |
Accessibility findings never block publishing. The scan is informational, and the publish button behaves the same whether you have critical issues, warnings, or no issues at all.
Where Severity Appears
Severity lives in the results, not on the readiness row. The chat summary card shows a written summary of the scan plus a Fix N issues button. Click the card to open the full report, where findings are grouped into Critical, Warnings, and Info, each with a count. If nothing was found, the report shows a green checkmark and “No accessibility issues found.”
What the Scanner Does Not Do
The accessibility scanner is a pre-publish code check, not a replacement for:
- WCAG compliance certification. Static analysis cannot prove full compliance. For legal or formal accessibility requirements, pair with manual testing and professional audits.
- Screen reader testing. The scanner does not run VoiceOver, NVDA, or JAWS. Test with real assistive technology for critical workflows.
- Real color contrast verification. The scanner flags Tailwind classes that often produce low contrast, but does not calculate actual ratios. Use browser DevTools or a contrast analyzer for precise measurements.
- Runtime behavior testing. Focus traps, modal interactions, live regions, and dynamic content need manual keyboard and screen reader testing.
Use the scanner alongside your existing accessibility practices, not instead of them.
FAQs
When should I run an accessibility scan?
Run a scan before your first publish and after significant changes to your UI, forms, or navigation.
How long does a scan take?
Most scans complete in about two minutes.
Is this like Lighthouse?
Similar goal, different method. Lighthouse tests a running page in a browser. The accessibility scanner analyzes your source code before publish. Faster, but focused on code-level issues rather than rendered behavior.
Why did it flag something that looks fine?
Static analysis cannot see component composition or runtime behavior. If a finding seems incorrect, expand it for details and ask the agent to investigate. You can fix real issues or skip false positives.
Do I need to re-run after fixes?
Yes. After the agent applies fixes, click Run audit on the approval card to confirm. The scan is the source of truth for whether issues are resolved.
Last updated: August 10, 2026
