Product Feature
Accessibility Audit for Design QA
An accessibility audit checks a live webpage against WCAG 2.2 Level A and AA success criteria using the axe-core engine. OverlayQA runs the audit directly in the browser during QA review, groups violations by severity, adds AI-powered fix suggestions, and exports findings to Jira or Linear as structured issues.
95.9% of the top one million websites have detectable WCAG failures, averaging 56.1 errors per page (WebAIM Million, 2025). Most teams discover these violations after launch, when fixes cost significantly more and require emergency patches. OverlayQA moves accessibility testing into the QA workflow so violations are caught on staging and preview deployments before they reach production.
How the accessibility audit works
- Open OverlayQA on the page — Navigate to any webpage (staging, localhost, or production) and open the OverlayQA sidebar from the Chrome extension toolbar.
- Start the accessibility audit — Click Workflows, select Accessibility Audit, and click Scan Page. The axe-core engine scans the full DOM for WCAG 2.2 Level A and AA violations. Optionally include a linked Figma frame for AI-powered visual comparison.
- Review violations by severity — Results are grouped into four levels: Critical, Serious, Moderate, and Minor. Each violation shows the affected element's CSS selector, the WCAG success criterion it fails, and an AI-generated explanation with a recommended fix in plain language.
- Export findings to your tracker — Export violations individually or in bulk to Jira or Linear. Each issue includes the violation description, severity, CSS selector, screenshot, and AI fix suggestion.
What gets flagged
The audit runs a four-step pipeline covering axe-core rule analysis, keyboard navigation checks, DOM structure validation, and optional AI visual analysis. Specific checks include:
- Color contrast — Text and interactive elements checked against WCAG 1.4.3 minimum contrast ratios (4.5:1 for normal text, 3:1 for large text).
- Alt text and image labels — Images, icons, and media elements checked for descriptive alternative text.
- ARIA attributes — Roles, states, and properties validated against WAI-ARIA specification requirements.
- Heading hierarchy — Heading levels checked for proper nesting (no skipped levels, single h1).
- Keyboard navigation — Focus visibility, keyboard traps, tab order, and touch target sizing evaluated.
- Form labels — Input elements checked for associated labels and accessible names.
Why accessibility auditing matters for QA teams
- Catches violations during QA, not after launch — Run audits on staging and preview deployments before accessibility issues reach real users.
- AI fix suggestions in plain language — Every violation comes with an AI-generated explanation and recommended fix, so developers know exactly what to change without researching WCAG criteria.
- No separate accessibility tool required — Run accessibility checks in the same pass as visual design QA instead of switching to a standalone scanner with its own workflow and issue tracker.
- Ignore false positives at page or project scope — Dismiss violations that do not apply, either for the current page or across all pages in the project. Restore ignored violations at any time.
- Bulk export to Jira or Linear — Select multiple violations and create structured issues in one action. Duplicate violations are automatically skipped.
Frequently asked questions
What WCAG criteria does OverlayQA check?
OverlayQA uses the axe-core engine to check WCAG 2.2 Level A and AA success criteria. This covers contrast ratios, alt text, ARIA attributes, heading hierarchy, focus order, keyboard navigation, touch target sizing, and form labels. AI visual analysis adds checks for layout and content readability issues that rule-based scanners cannot detect.
How is this different from axe DevTools or WAVE?
Standalone accessibility tools require a separate workflow and separate issue tracking. OverlayQA runs axe-core inside your existing QA review, adds AI-powered fix suggestions to every violation, and exports findings directly to Jira or Linear as structured issues. You can also run accessibility and visual design QA in the same pass.
Can I ignore false positives?
Yes. You can ignore violations at two scopes: per-page (hidden on the current URL only) or per-project (hidden for that selector and WCAG criterion across all pages). Ignored violations move to a separate section and can be restored at any time.
Does it work on localhost and staging environments?
Yes. OverlayQA runs directly in the browser, so it works on any URL including localhost, staging previews, and production pages. No server-side setup is required.