Best Accessibility Testing Tools for Websites

There is no evidence-backed universal winner among website accessibility testing tools. Choose based on whether you need quick browser inspection, visual discovery, guided manual review, or repeatable checks in a development pipeline. Use automated scans to find detectable issues, then verify findings with people, keyboard testing, and relevant assistive technology. A scan or score cannot prove that a site is accessible.

This guide compares the main tool options, shows runnable examples for a repeatable check, and lays out a workflow for testing pages and fixing findings. For authoritative context, see the W3C Web Accessibility Evaluation Tools List and the W3C evaluation guidance.

What accessibility testing tools can and cannot tell you

Automated tools detect some rule-based issues in the page state they can inspect. Depending on the tool and configuration, findings may include missing accessible names, invalid ARIA usage, or contrast concerns. They cannot reliably judge every issue that depends on meaning, context, task completion, or how a person experiences the service.

WAVE states that no automated tool checks every issue in WCAG 2.2 or Section 508, and that humans determine whether a page is accessible. The UK Department for Work and Pensions also describes automated tools as a useful starting point while cautioning that they cannot find every error or guarantee accessibility. Treat results as evidence to investigate, not a compliance certificate.

• Automated checks: useful for repeatable, detectable rule violations.
• Guided evaluation: helps a reviewer organize and perform checks that need judgment.
• Manual and assistive technology testing: reveals issues in actual navigation, comprehension, and task completion.
• Professional evaluation: can add assurance when the service, risk, or obligation warrants it.

Best accessibility testing tools by job

The options below serve different purposes; they are not ranked by a shared benchmark. Pick one or more that fit the team’s workflow, then combine them with manual testing.

Tool	Best fit	Documented capabilities	Limit to keep in mind
axe DevTools	Browser-based discovery and developer evaluation	The W3C tools catalog lists automated, semi-automated, and manual testing, with WCAG 2.2, 2.1, and 2.0 associations. UK Department for Education guidance describes a browser extension with findings grouped by severity.	Verify each finding in context. The cited government page lists Chrome, Edge, and Firefox and says Safari is unsupported; check current vendor documentation for current browser support.
WAVE	Visual inspection of a rendered page	WebAIM offers an online evaluation tool, browser extension, and API/testing offerings for larger-scale data collection. Its documentation describes checks related to WCAG 2.2 and Section 508.	WAVE says automated checks cannot cover every guideline issue. Its remote evaluation may not fully apply JavaScript because of security limitations.
Lighthouse	A quick check from Chrome DevTools	Government digital service guidance includes Lighthouse among automated accessibility tool examples.	Use it as one input to a broader evaluation; the cited guidance does not establish complete standards coverage.
Pa11y and axe-core	Repeatable checks in development or acceptance-test workflows	Government guidance describes Pa11y as an automated tool that integrates with axe-core and a headless browser. axe-core can be used in acceptance tests and bulk checks.	Pipeline checks still cover detectable rule-based issues only. Keep human review in the workflow.
Guided/manual evaluation tools	Structured human review	The W3C catalog distinguishes fully automated tools from tools that help manual review or simulate user experience. Government guidance recommends guided assessment and manual testing.	A tool cannot replace reviewer judgment or the experience of people using assistive technology.

How to choose

• Testing mode: Does the tool automate checks, guide manual review, or support both?
• Scope: Can it inspect one rendered page, a local development build, multiple routes, or restricted pages behind authentication?
• Rules and standards: Are the specific rules and guideline associations documented? Do not infer full conformance from a standards label.
• Environment: Which browsers and operating systems does it support, and can your team reproduce results there?
• Integration: Can developers run checks in a local workflow or acceptance tests without making failures too noisy to act on?
• Report quality: Does each finding explain the affected element, evidence, and a useful next step? Can the team track verification and fixes?

The W3C catalog records dimensions such as tool purpose, scope, browser, operating system, and output. Use those dimensions to compare fit rather than relying on a single score.

A practical website accessibility testing workflow

1. Choose representative pages and states. Include high-traffic templates, forms, menus, dialogs, and important task flows. Test meaningful states such as validation errors and expanded menus, not just the initial page.
2. Run an automated scan early. Scan representative pages and shared components while changes are still easy to make. Record the page, state, tool, and rule or finding.
3. Triage and verify every finding. Inspect the element and its context. Determine whether the reported problem exists, whether the suggested fix preserves meaning and behavior, and whether related pages share the same component.
4. Manually use the site. Navigate with a keyboard, check focus visibility and order, use forms and interactive controls, and confirm that errors and status changes are understandable.
5. Test with relevant assistive technology. Include screen-reader checks for the operating systems and browsers your audience uses. Automated tools cannot establish that the experience is understandable or that a task can be completed.
6. Automate suitable repeatable checks. Add stable checks to acceptance tests where they provide actionable feedback. Pa11y and axe-core are options described in government guidance.
7. Retest after fixes and meaningful changes. Recheck the original issue, nearby behavior, and affected templates. Repeat testing when changes alter the relevant flow or components.
8. Escalate when assurance needs it. For higher-risk services or formal assurance needs, include qualified professional evaluation alongside automated and manual checks.

Runnable example: add an automated check with Pa11y

Pa11y is one option for repeatable automated checks. The following is a minimal local example for a page you are authorized to test. It reports detectable findings; it does not certify the page or replace manual review. Install a current supported Node.js release first, then create a small project:

mkdir accessibility-check
cd accessibility-check
npm init -y
npm install --save-dev pa11y

Save this as check.js, replacing the example URL with your local development page or another page you are authorized to test:

const pa11y = require('pa11y');

async function main() {
  const url = process.argv[2] || 'https://example.com';
  const results = await pa11y(url);

  console.log(`Tested: ${url}`);
  console.log(`Findings: ${results.issues.length}`);
  for (const issue of results.issues) {
    console.log(`\n[${issue.type}] ${issue.code}`);
    console.log(issue.message);
    if (issue.selector) console.log(`Selector: ${issue.selector}`);
    if (issue.context) console.log(`Context: ${issue.context}`);
  }
  if (results.issues.length > 0) process.exitCode = 1;
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 2;
});

Run it with:

node check.js https://example.com

In a project that uses ES modules, configure the project accordingly or use the import form supported by your installed Pa11y version. Pin dependencies in your project lockfile so local and CI runs use the same versions. Before making this a required CI gate, review how your team wants to handle tool errors, known findings, dynamic content, and intentionally excluded rules; avoid suppressing issues without a documented reason and a follow-up owner.

For a complementary browser-based check, open the page in Chrome DevTools and run Lighthouse. For visual inspection, use WAVE on the rendered page or its browser extension. Consult each tool’s current official documentation for installation, options, supported environments, and version-specific configuration.

Manual checks an automated scan will miss

• Keyboard: Can you reach and operate every control without a pointer? Is focus visible and in a useful order? Can you leave menus, dialogs, and other components?
• Meaning and labels: Do headings, link names, form labels, instructions, and error messages make sense when read outside their visual layout?
• Task completion: Can a person complete the key task, recover from an error, and understand the result?
• Dynamic behavior: Are updates, validation messages, and opened or closed states communicated appropriately?
• Zoom and layout: Does content remain usable when enlarged or when the viewport changes?
• Assistive technology: Does the experience work with relevant screen readers and other technologies, not just satisfy a static markup rule?

These checks require human evaluation. Involve people with disabilities in research and evaluation when possible, and use qualified accessibility practitioners when the level of assurance calls for it.

Common problems and how to resolve them

Problem	Likely cause	What to do
A scan reports no issues, but users still encounter barriers.	The tool only detects certain rule-based problems in the page state it inspected.	Test the task manually with keyboard and relevant assistive technology. Review content meaning, focus behavior, and dynamic states.
A reported finding appears incorrect.	The rule may not understand page context, or the inspected state may differ from the one the user experiences.	Reproduce the state, inspect the element and its relationships, and document why the finding is or is not an issue. Do not dismiss findings solely to get a clean report.
A remote visual check misses JavaScript-rendered content.	The remote service may not fully apply JavaScript because of security or execution limitations.	Use a browser extension or a local browser-based scan on the fully rendered page, then test the relevant interaction manually.
Automated checks are noisy in CI.	Tests may scan unstable states, include unrelated third-party content, or fail without a triage policy.	Choose stable representative states, make failures actionable, assign findings, and document justified exclusions. Keep a manual evaluation step.
A browser extension is unavailable in the team’s browser.	Tool support varies by browser and may change over time.	Check current vendor support and use an available browser or another tool that fits the environment. Preserve manual checks across environments.
A fix clears one page but the same issue appears elsewhere.	The underlying component or template is shared across routes.	Fix the shared source where appropriate, then scan representative pages that use it and retest the affected flow.

Performance, reliability, and cost considerations

For accessibility testing, the main practical cost is the time required to review findings and validate behavior, plus any licensing or infrastructure for the tools selected. The supplied research does not establish current prices or comparative scan performance for these tools, so check vendor sources before making a purchasing decision.

• Run scans early and selectively: Start with representative templates and shared components, then expand to important routes and states.
• Keep runs reproducible: Record tool and dependency versions, the page state, and relevant browser environment so changes in output can be investigated.
• Make CI output actionable: Use stable pages and avoid making an unexplained score the release criterion. Track findings through verification and repair.
• Plan for dynamic pages: A scan cannot evaluate an interaction state it never reaches. Arrange for the relevant content to be present or test it after the interaction.
• Budget for human review: Automation can reduce repetitive checks, but keyboard, assistive technology, and contextual evaluation still require time.

Screenshot an accessibility test state

A screenshot can help document the visual state associated with a finding, such as a form error, a focus indicator, or a dialog. It is supporting evidence only: an image cannot show keyboard operability, screen-reader output, or whether a task is understandable. Capture the relevant state and pair it with the test steps and finding details.

For a direct browser capture, open the page at the relevant state and use the browser’s screenshot capability. If you need an API instead of maintaining browser capture setup, ScreenshotNeo is a website screenshot API and MCP server for developers. Its cookie and consent handling accepts consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Only clean shots are billed: bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with the result identified in response headers. The API supports screenshots and PDFs, and an MCP server offers screenshot tools for AI agents.

Or skip the browser setup

Use this one-call example to capture a page. Replace the target URL as needed and keep your API key private. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. You get 1,000 screenshots a month free with no card; paid plans start at $5 for 3,000. Sign up for the free plan.

Frequently asked questions

Can an accessibility checker tell me if my site is WCAG compliant?

No. An automated checker can identify some detectable issues, but it cannot determine every contextual or user-experience question. Conformance evaluation requires human review across relevant pages and states.

Should every automated finding block a release?

Establish a triage policy based on verified impact and your release process. Investigate findings, record decisions, and keep unresolved barriers visible; a clean scan is not a reason to skip manual checks.

How often should a site be tested?

Test during development, after changes to relevant components or flows, and as part of ongoing evaluation. The right cadence depends on how often the service changes and the assurance it needs.

Do I need more than one tool?

Usually, a useful setup combines an automated tool for repeatable checks with manual evaluation. A second automated tool can add a different workflow or presentation, but does not remove the need for human testing.

Sources and further reading

• W3C WAI: Web Accessibility Evaluation Tools List (catalog entry last updated April 2025).
• W3C WAI: Test and Evaluate.
• WebAIM WAVE and WAVE help documentation.
• UK Government Service Manual: Testing for accessibility.
• UK Government: Accessibility requirements for public sector websites and apps.

ScreenshotNeo is made by Yorker Media. Use screenshots as visual records of test states alongside, never instead of, interaction and assistive technology evaluation.