7 Best WCAG Testing Tools in 2026, Compared

What Are WCAG Testing Tools?

WCAG testing tools are software that helps teams evaluate websites against the Web Content Accessibility Guidelines (WCAG). These guidelines define success criteria across four principles: Perceivable, Operable, Understandable, and Robust. Each criterion has a conformance level (A, AA, or AAA), with AA being the standard most regulations require.

WCAG testing tools range from browser extensions that flag missing alt text to enterprise platforms that scan entire domains on a schedule. Some are free. Some cost six figures annually. The right combination depends on your team size, regulatory exposure, and how deeply accessibility is embedded in your development process.

Note: WCAG versions at a glance: WCAG 2.0 (2008) introduced the four principles. WCAG 2.1 (2018) added 17 criteria for mobile and cognitive accessibility. WCAG 2.2 (2023) added 9 more criteria covering focus appearance, dragging movements, and target size. Most regulations reference WCAG 2.1 AA, but teams building for longevity should target 2.2.

Why Teams Need More Than One Tool

The UK Government Digital Service research and multiple independent studies consistently find that automated accessibility testing catches only 30-35% of WCAG issues. The Deque research team, who build axe, publicly state that automation covers about 57% of issues, and even that figure requires their full enterprise suite running in CI, not just a browser extension scan.

What does the other 65% look like? It is the stuff that requires eyes and judgment:

• Contrast in context. A color combination passes the 4.5:1 ratio check in isolation but fails when rendered over a gradient background or image.
• Focus indicator visibility. A focus ring exists in the DOM but is visually indistinguishable from the surrounding UI: technically present, practically invisible.
• Touch target sizing. WCAG 2.2 requires 24x24px minimum targets. A button renders at 44x44px on desktop but shrinks below threshold on mobile viewports.
• Content reflow. The page passes at 1280px but breaks at 320px: content overflows, controls overlap, or reading order changes.
• Meaningful reading order. Screen readers traverse the DOM order, not the visual order. CSS Grid and Flexbox can make the visual layout logical while the DOM order is nonsensical.
• Error identification. The form shows a red border on error, but the error message is not programmatically associated with the input, so screen readers do not announce it.

None of these issues can be reliably caught by running a scanner. They require someone to look at the page, interact with it, and compare what is rendered against what accessibility requires. That is where design QA and manual testing fill the gap.

The Three Layers of WCAG Testing

Think of WCAG compliance testing as three layers. Each catches a different class of issue. Skip any layer and you have blind spots.

Layer 1: Automated Scanning

Automated scanners parse the DOM and evaluate rules programmatically. They are fast, consistent, and excellent at catching structural issues: missing alt attributes, empty buttons, duplicate IDs, missing form labels, insufficient color contrast ratios (in isolation), and ARIA misuse. To spot-check one of those categories fast, our free alt text checker scans every image on a URL for missing alt attributes, filename-as-alt, and redundant phrasing.

Best for: Catching low-hanging fruit at scale. Running in CI to prevent regressions. Establishing a baseline before deeper testing.

Misses: Anything that requires visual context, user interaction patterns, or judgment about whether the experience (not just the markup) is accessible.

Layer 2: Design QA and Visual Accessibility Review

Design QA catches the accessibility issues that live in the visual layer: the gap between what the design specified and what the browser actually renders. This includes contrast failures that only appear in context, focus indicators that technically exist but are invisible, spacing that breaks touch targets, and component states that were designed accessibly but implemented without the accessible styles.

This layer is where a tool like OverlayQA fits. By comparing the Figma design against the live staging build, teams can verify intended accessibility treatments (focus rings, contrast, spacing, target sizes) against what actually shipped. When something does not match, OverlayQA captures the element, extracts the CSS values, and exports a structured issue to Jira, Linear, or Notion, so the developer gets exactly the values they need to fix it.

Best for: Catching visual accessibility failures that scanners miss. Verifying that accessible design intent survived the implementation process. Bridging design and development on accessibility standards.

Layer 3: Manual Testing with Assistive Technology

The final layer is testing with the actual tools your users rely on: screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, switch devices, and screen magnifiers. This is the only way to verify that the experience, not just the markup, works for people with disabilities.

Best for: Validating reading order, announcement quality, keyboard workflows, and interaction patterns that cannot be evaluated by looking at code or visuals alone.

Requires: Trained testers who understand assistive technology behavior. This layer is time-intensive but irreplaceable for WCAG conformance claims.

WCAG Testing Tool Comparison

The following table compares the most widely used accessibility testing tools across all three layers. Each tool has a different sweet spot; the goal is to pick one from each layer, not to find the one tool that does everything.

Tool Deep Dives

axe DevTools by Deque

axe is the industry standard for automated accessibility testing. The open-source axe-core engine powers most other tools on this list (Lighthouse uses a subset of axe rules). The browser extension is free and gives you a panel in DevTools that scans the current page and highlights violations with WCAG references and fix suggestions.

The enterprise version adds guided manual testing flows, issue management, and CI integration via their testing library. If you are picking one automated scanner, axe is the safest default. It has the largest rule set, the most active development, and broad framework support.

Best for: Teams that want one scanner covering the widest range of automated checks. Works standalone or embedded in Cypress, Playwright, and Jest test suites.

WAVE by WebAIM

WAVE takes a visual approach to accessibility testing. Instead of listing violations in a panel, it injects icons directly into the page, showing you where errors, alerts, and ARIA issues occur in context. This makes it easier for non-technical team members (designers, PMs, content writers) to understand what is wrong and where.

WAVE also provides a contrast checker, heading structure outline, and tab order visualization. The API version enables batch scanning for larger sites. The visual feedback model makes WAVE the most accessible accessibility tool, useful for teams where not everyone reads DevTools. If you only need a quick heading outline without installing an extension, our free heading checker extracts the full H1-H6 hierarchy from any URL and flags skipped levels.

Best for: Designers and PMs who need visual feedback on accessibility issues without opening DevTools. Quick page-level scans.

Google Lighthouse

Lighthouse is built into Chrome DevTools and runs accessibility checks as part of its broader performance, SEO, and best-practices audit. It uses a subset of axe-core rules, so its accessibility score is a useful baseline but not comprehensive. A page can score 100 on Lighthouse accessibility and still have dozens of WCAG violations that Lighthouse does not test for.

Lighthouse is most useful as a quick sanity check during development and as a CI gate to catch obvious regressions. Do not treat the accessibility score as a conformance indicator.

Best for: Quick baseline checks during development. CI integration for catching regressions. Not sufficient as your only accessibility testing tool.

Pa11y

Pa11y is an open-source command-line accessibility testing tool. It runs headless Chrome, loads pages, and evaluates them against WCAG criteria using either the axe-core or HTML_CodeSniffer engine. The Pa11y CI runner integrates into build pipelines and can test multiple URLs per run.

Pa11y is a strong choice for teams that want free, self-hosted accessibility testing in CI without vendor lock-in. The trade-off is less polish: no GUI, no issue management, no guided remediation. You need a developer to set it up and interpret the output.

Best for: Engineering teams that want free, open-source accessibility testing in CI. Self-hosted environments where SaaS tools are not an option.

Deque axe Monitor

axe Monitor is Deque's enterprise scanning platform. It crawls your entire site on a schedule, tracks issues over time, and generates compliance reports. Where the axe DevTools extension tests one page at a time, axe Monitor tests thousands of pages automatically and tracks whether your WCAG conformance is improving or regressing across releases.

Best for: Enterprise teams managing large sites (1,000+ pages) that need ongoing compliance monitoring and executive-level reporting. Typically paired with axe DevTools for developer-level testing.

Siteimprove

Siteimprove is a digital governance platform that bundles accessibility testing with content quality, SEO, and analytics. Its accessibility module scans against WCAG 2.1 and 2.2 criteria, assigns issues a severity score, and provides plain-language fix guidance. It also generates conformance reports suitable for procurement (VPAT-ready; see our VPAT template guide).

Best for: Organizations that need accessibility as part of a broader digital governance strategy. Common in higher education, government, and healthcare.

OverlayQA: Design QA for Accessibility

OverlayQA is a browser-based design QA platform that helps teams catch the accessibility issues that live in the visual layer, the issues automated scanners miss. The accessibility audit workflow lets teams compare Figma designs against staging builds and systematically verify what was designed against what was implemented.

Where an automated scanner tells you "this element has insufficient contrast," OverlayQA shows you why it happened: the designer specified #1a1a1a on #ffffff (passing), but the developer implemented #6b7280 on #f3f4f6 (failing). You see the drift, capture the exact CSS values, and export a structured issue with all the context the developer needs to fix it.

• Contrast verification in context. Check color contrast as it actually renders: over backgrounds, gradients, and images, not just in isolation.
• Focus indicator review. Tab through the page with the Figma overlay active. Compare designed focus states against implemented ones.
• Touch target sizing. Compare the design against the build to verify that interactive elements meet WCAG 2.2's 24x24px minimum target size on mobile viewports.
• Spacing and reflow. Compare responsive layouts at breakpoints to catch content overlap, truncation, and reflow failures.
• Component state coverage. Verify that all interactive states (hover, focus, active, disabled, error) were implemented, not just the default state.

OverlayQA does not replace automated scanners. It fills the gap between what scanners catch and what assistive technology testing requires. Think of it as the visual verification layer that ensures accessible design intent survived the implementation process.

Best for: Product teams where designers and developers share responsibility for accessibility. Teams that have already run automated scans but know they are missing visual issues. Any team transitioning from "accessibility as an afterthought" to "accessibility as part of design QA." Compare how OverlayQA differs from general feedback tools on our OverlayQA vs Marker.io comparison, or see how it compares to BugHerd, which focuses on visual feedback but has no WCAG testing capabilities.

What Automated Tools Catch vs. What They Miss

Understanding the boundary of automation is critical. Here is a concrete breakdown:

The pattern is clear: automated tools catch structural presence (does the attribute exist?) but not experiential quality (does it actually work for users?). That gap is where design QA and manual testing earn their keep.

How Design QA Fills the Accessibility Gap

Most accessibility failures are not code-level mistakes. They are visual implementation gaps: places where the accessible design was specified correctly but the implementation drifted. A product designer designs a focus ring with a 3px solid outline in the brand color. A developer implements it with a 1px dotted border that is nearly invisible. The scanner does not flag it because a focus style exists. But the user who relies on keyboard navigation cannot see it.

Design QA catches these gaps by comparing the design spec against the live implementation. Here are the specific accessibility categories where design QA adds the most value:

• Contrast in context. A color passes the ratio check on a flat background but fails when rendered over a hero image. Design QA catches this by reviewing contrast as the user sees it, not in a lab.
• Focus indicators. WCAG 2.2 (2.4.11, 2.4.12) requires focus indicators to meet minimum area and contrast requirements. Design QA compares the designed focus state against the implemented one to verify it meets the criteria.
• Touch targets. WCAG 2.2 (2.5.8) requires interactive targets to be at least 24x24 CSS pixels. Design QA verifies target sizing across viewports by comparing the design against the build at each breakpoint.
• Spacing and reflow. WCAG 1.4.10 requires content to reflow without loss of information at 320px width. Design QA compares the responsive behavior against the design spec to catch overflow, truncation, and overlap.
• State coverage. Accessible designs include hover, focus, active, disabled, and error states for every interactive component. Design QA verifies that all specified states were implemented, not just the default. Missing states are one of the most common UI bugs.

WCAG 2.1 vs WCAG 2.2: Which Version to Target

WCAG 2.2 became a W3C Recommendation in October 2023. It is the current standard. But most regulations, including ADA Title II, Section 508, and the EN 301 549 (European standard), still reference WCAG 2.1 AA. So which should your team target?

Tip: Target WCAG 2.2 AA. It is backwards-compatible with 2.1: every 2.2 conformant site also conforms to 2.1. By targeting 2.2 now, you meet current regulatory requirements and prepare for inevitable updates. The additional criteria in 2.2 address real usability issues (focus appearance, target size, dragging alternatives) that improve the experience for everyone.

Key additions in WCAG 2.2 that affect design and implementation:

• 2.4.11 Focus Appearance (AA): Focus indicators must have a minimum area (at least a 2px perimeter) and sufficient contrast (3:1 against adjacent colors).
• 2.4.12 Focus Not Obscured (AA): The focused element must not be fully hidden by sticky headers, modals, or other overlapping content.
• 2.5.7 Dragging Movements (AA): Any functionality using dragging must have an alternative input method (click, tap, or keyboard).
• 2.5.8 Target Size (AA): Interactive targets must be at least 24x24 CSS pixels, with exceptions for inline text links and elements where size is essential.
• 3.3.7 Redundant Entry (A): If a user already entered information in a multi-step process, it must be auto-populated or selectable, not required to be re-entered.

These criteria make the design-to-implementation gap even more important to test. Focus appearance, target size, and dragging alternatives are all design decisions that need implementation verification. That is exactly what visual comparison tools are built for.

A Practical WCAG Testing Workflow

Here is a three-layer testing workflow that combines automated scanning, design QA, and manual testing into a repeatable process. This is not theoretical. It is what teams with mature accessibility practices actually do.

Step 1: Automated Scan in CI (Every Build)

Integrate axe-core into your test suite (Cypress, Playwright, or Jest). Run it on every pull request. Fail the build on critical violations (missing labels, empty buttons, broken ARIA). This catches regressions instantly and keeps the structural baseline clean.

Step 2: Design QA Review (Every Sprint)

Before a feature merges, open the staging build in OverlayQA and compare the Figma design against it. Check:

• Do focus indicators match the design spec? Tab through every interactive element.
• Does text contrast pass in context, over backgrounds, gradients, and images?
• Are touch targets at least 24x24px at mobile viewports?
• Do all component states (hover, focus, active, disabled, error) match the design?
• Does the layout reflow correctly at 320px without content loss?

Any issue gets captured with CSS values and exported to your tracker. No screenshots-in-Slack. No guessing.

Step 3: Assistive Technology Testing (Every Release)

Before each release, test the critical user flows with a screen reader (NVDA on Windows, VoiceOver on Mac), keyboard-only navigation, and screen magnification at 200%. Verify that:

• Reading order matches visual order on every page.
• All interactive elements are reachable and operable via keyboard.
• Screen reader announcements are meaningful, not just "button" or "link" but context-rich labels.
• Modal focus trapping works (focus stays inside the modal until dismissed).
• Dynamic content updates (toasts, live regions) are announced.

This three-layer approach covers the full WCAG surface area: structural correctness (automated), visual accessibility (design QA), and experiential quality (assistive technology). No single layer is sufficient. Together, they are comprehensive.

Common WCAG Testing Mistakes

• Treating a Lighthouse score as proof of conformance. Lighthouse tests a subset of WCAG criteria. A 100 score means you passed those checks, not that your site is accessible.
• Testing only on desktop. WCAG 2.1 and 2.2 include mobile-specific criteria (touch targets, orientation, motion). Test at 320px, 375px, and 768px, not just 1280px.
• Running scans only in pre-production. Content changes, CMS updates, and third-party script injections can introduce accessibility issues at any time. Schedule regular scans on production.
• Ignoring the design layer. If the design specifies accessible treatments but implementation drifts, no automated tool will catch it. Design QA is the verification layer.
• Skipping keyboard testing. This is the single most impactful manual test. If a sighted user can tab through every interactive element and understand where they are, the keyboard experience is likely solid.

Frequently Asked Questions

What is the best free WCAG testing tool?

axe DevTools (browser extension) is the most comprehensive free automated accessibility testing tool. For a visual approach, WAVE is also free and excellent for non-technical team members. Both are useful starting points, but neither catches the full range of WCAG issues; you still need design-level and manual testing. For a scan that pairs axe-core with AI visual analysis, OverlayQA's free accessibility checker runs on any public URL with no account required.

Can automated tools guarantee WCAG compliance?

No. Automated tools catch approximately 30-35% of WCAG issues, primarily structural and programmatic checks. Conformance claims require human evaluation of visual presentation, interaction quality, and assistive technology compatibility. There is no tool that can run a scan and certify your site as WCAG compliant.

How does design QA improve accessibility testing?

Design QA catches the visual accessibility issues that automated scanners miss: contrast in context, focus indicator quality, touch target sizing, and component state coverage. By comparing the design spec against the staging build, design QA verifies that accessible design intent was preserved through implementation. This fills the gap between automated scanning and manual assistive technology testing.

Start Catching What Scanners Miss

Automated scanners catch the structural issues. Assistive technology testing catches the experiential issues. OverlayQA catches the visual accessibility issues in between: the contrast failures, missing focus states, undersized targets, and implementation drift that create the majority of real-world WCAG violations.

Compare your Figma designs against staging. See what was designed vs. what was built. Export structured issues to Jira, Linear, or Notion with the exact CSS values developers need to fix them. Start your free 14-day trial and add the design QA layer to your accessibility testing workflow.

Try it now: Scan your site for free with our accessibility checker. It combines axe-core automated testing with AI visual analysis to catch what scanners alone miss.

OverlayQA combines axe-core automated checks with AI visual analysis for comprehensive WCAG testing. Scan entire pages, filter by severity, and export violations to Jira, Linear, Asana, or Trello with CSS selectors attached.