Product Feature
Accessibility Audit for Design QA
Last updated
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 in the browser during QA review, groups violations by severity, adds AI-powered fix suggestions, and exports findings to Jira, Linear, Notion, Asana, or Trello as structured issues.
95.9% of the top one million websites have detectable WCAG failures, averaging 56.1 errors per page (WebAIM Million, February 2026). 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, Linear, Notion, Asana, or Trello. 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 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, Linear, Notion, Asana, or Trello: Select multiple violations and create structured issues in one action. Duplicate violations are automatically skipped.
Run it in Team Review with no extension
On any public URL, open the page in Team Review from the OverlayQA dashboard and the accessibility audit runs natively, with nothing installed. Use the Chrome extension for localhost, staging, and login-gated pages.
Scheduled re-scans with change emails
Schedule a page for a recurring accessibility scan, weekly by default or daily or monthly. OverlayQA emails a baseline after the first run, then only when a re-scan finds something new or fixed. See scheduled scans.
Findings become tracked issues
Turn violations into issues with the failing element, WCAG criterion, severity, and a suggested fix, then export to Jira, Linear, Notion, Asana, or Trello with two-way sync: status, assignee, and comments sync back. Fingerprint-based dedup and two-scope ignore keep known violations out of the way.
Accessibility scans for AI coding agents
The OverlayQA MCP server gives agents like Claude Code and Cursor an accessibility scan tool, so an agent can scan a page, create issues from the findings, and update those issues as it fixes them.
Frequently asked questions about the accessibility audit
- What is an accessibility audit?
- 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, Linear, Notion, Asana, or Trello as structured issues.
- 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 to Jira, Linear, Notion, Asana, or Trello 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. Violations are also deduplicated by fingerprint.
- Does it work on localhost and staging environments?
- Yes. The Chrome extension runs the audit in your own browser session, so it works on localhost, staging previews, login-gated pages, and production. No server-side setup is required.
- Do I need to install anything to run an accessibility audit?
- Not for a public URL. Open the page in Team Review from the OverlayQA dashboard and the accessibility audit runs natively with no extension. Install the Chrome extension only for localhost, staging, and login-gated pages.
- Can OverlayQA re-check a page automatically?
- Yes. Scheduled scans re-run the accessibility audit on a page daily, weekly, or monthly, with weekly as the default. You get a baseline email after the first scan, then an email only when a re-scan finds something new or fixed.
- Can AI coding agents run accessibility scans?
- Yes. The OverlayQA MCP server gives agents like Claude Code and Cursor an accessibility scan tool. An agent can scan a page, create issues from the findings, and update those issues as it fixes them.
- What happens to violations after the scan?
- Each violation can become a tracked issue with the failing element, WCAG criterion, severity, and a suggested fix. Export to Jira, Linear, Notion, Asana, or Trello, and status, assignee, and comments sync back. You can also copy findings to the clipboard as Markdown or CSV.
- Is OverlayQA an accessibility audit Chrome extension?
- Yes. The OverlayQA Chrome extension runs axe-core WCAG 2.2 Level A and AA checks on any page you can open, including localhost, staging and login-gated pages, and turns each violation into a tracked issue with its CSS selector and screenshot. Team Review runs the same audit from the dashboard on any public URL with no extension installed.