A useful accessibility testing stack helps your team find barriers, understand their effect on people and turn findings into changes. Start with page checks such as WAVE or Lighthouse, add guided and manual evaluation, then choose a repair route that fits where your team works. You do not need every product in this guide.
Compare the options on three things: what they evaluate, what you get back and who reviews and makes the change. A browser report, a design-file suggestion, an expert audit and a source-code fix serve different parts of the job.
Artie publishes this guide. Its AI employee Mona is included for a combined page-and-design review that can return a draft pull request or Figma corrections, with options for changes that need a design decision.
Start with page checks and guided evaluation
WAVE: inspect a page and interpret its findings
WAVE is a practical starting point for reviewing an existing page. Its online tool accepts a URL, while its browser extensions can check password-protected, local and highly dynamic pages. It identifies accessibility errors and supports human evaluation, so the useful next step is to examine the flagged content in context and decide how to correct it.
WAVE also has routes beyond individual page reviews. Its APIs collect test data across multiple pages, and the standalone testing engine can work inside your infrastructure and continuous integration process. For teams that want expert interpretation, WebAIM's AIM assessment combines WAVE data with manual test results in a report. That gives WAVE a place in both a basic page check and a broader evaluation program.
Lighthouse: use the score to investigate specific audits
Lighthouse's accessibility score summarizes automated checks using weights based on their impact. Each scored accessibility audit passes or fails. The practical value is in the individual results: a failed naming or labeling check tells a developer what to investigate next.
Google excludes manual audits from the score. A high score therefore leaves those checks unanswered. Use the report to find and revisit specific issues, while keeping the manual review alongside it.
Accessibility Insights: guide the person doing the review
Accessibility Insights for Web suits teams that want help carrying out a review, as well as automated findings. FastPass pairs automated checks with tab-stop assistance, including instructions and a visual helper for inspecting keyboard access.
Its Assessment mode adds guided manual tests, examples and guidance on fixing issues. This makes it useful for a developer who can inspect the page but wants a structured way to work through the human checks. The reviewer performs those checks and uses the findings to direct the changes.
axe DevTools Extension: bring guided tests into the browser
Deque's axe DevTools Extension combines Intelligent Guided Tests with advanced rules in the browser. It belongs on a shortlist for developers who want to investigate accessibility while working with the page itself.
The same extension also has a role later: Deque's audit service lets teams rescan and verify fixes with it.
Make room for manual and assistive testing
W3C explains that tools cannot automatically check every aspect of accessibility and that human judgment is required. A useful testing mix therefore includes people who can evaluate the content and the experience of using it.
Harvard's testing guidance separates content review, keyboard testing and screen-reader review. These answer different questions: does the content communicate clearly, can someone operate the interactive elements with a keyboard, and does the reading order make sense through a screen reader? Its mobile guidance also includes TalkBack and VoiceOver.
Plan this work with reviewers who know the relevant assistive technology, and include testing with people who use it. Their experience can reveal problems with the flow and design choices that a list of flagged elements does not explain. The output should connect a barrier to the affected task so the team understands what needs to change.
Keep design and development work connected
Stark: carry accessibility work from designs into code
Stark's design tools fit teams that want accessibility review inside their ongoing product process. Sidekick scans Figma or Sketch files and suggests fixes. Accessibility annotations in Figma's Dev Mode become code snippets for developers, giving the implementation team something concrete to work from.
The work continues in development. Stark's browser tools highlight affected code and offer a live preview for testing fixes. GitHub scanning and continuous scans of design files and repositories help teams revisit issues as the product changes. Reports bring design and code findings together, while its Compliance Center organizes controls and evidence.
For a team maintaining a shared design system and shipping regularly, that continuity is the reason to consider Stark. Designers and developers can address the same accessibility work in their respective tools rather than treating the design review as a separate document.
Siteimprove: organize issues and track progress
An ongoing platform also has a place when the immediate problem is coordinating a backlog of accessibility work. Harvard describes Siteimprove, its licensed tool, as breaking issues into manageable tasks, tracking progress and providing recommendations and guidance.
That is a useful distinction from an isolated page result. A product lead needs to see which issues the team is working through over time, as well as what the latest check found.
Choose how findings become fixes
Deque: code fixes through agents or expert remediation
Deque's Axe MCP Server brings accessibility guidance and contextual code fixes into compatible coding agents, including Claude Code, Cursor and GitHub Copilot. Developers can review, apply or reject fixes in their development environment. This fits a team that wants accessibility work inside its existing coding process.
Deque also offers a service route. Its accessibility audits combine automated and manual testing, return prioritized results and provide developer guidance or expert remediation. Its remediation specialists change the source code directly and validate the results through testing.
Pick the agent route when your developers want each fix proposed inside their coding tool. Pick the services when you want Deque's experts to test, repair the source and validate the result.
AudioEye: page interaction, agent-assisted fixes and expert work
AudioEye's Agentic Audits interact with a chosen page by opening menus, entering text and moving through flows. They return findings and fix recommendations for developers. This is an option for investigating how a rendered page behaves, including its interactive parts.
Its SDK MCP supports a related repair route through Claude Code, Codex and other compatible agents. It can scan a running local page, write source-code corrections and rescan for the issue. Developers review the changes before shipping them. Reports include issue locations and the associated WCAG criteria, making the results usable outside the coding session too. This route requires an AudioEye account with Testing SDK access.
AudioEye also offers expert audits using screen readers and other assistive technology, alongside custom fixes written and deployed by its experts. AudioEye says an Agentic Audit does not replace an Expert Audit, and positions it as coverage between audit cycles.
accessWidget: an installed website adjustment route
accessiBe's accessWidget is a paid service that works through an installed website layer, with recurring scans and automated adjustments. Visitors can also use profiles and controls to change the interface. This puts the implementation on a different surface from a source-code pull request.
Its offering also includes expert testing of core flows with assistive technology. Findings can lead to tailored code enhancements applied directly to accessWidget, with a report of what was tested and fixed. The practical difference is where the change lives: the experts apply their tailored enhancements to accessWidget itself, so the corrections run through the installed service.
Artie with Mona: a combined page-and-design pass with reviewable changes
Mona's accessibility review fits a product lead who wants a bounded page-and-design pass that returns changed files and makes unresolved design choices explicit. Mona checks pages in a browser with automated and by-hand checks, including contrast, text alternatives, heading order, keyboard focus, form labels and zoom. She can also review Figma designs before they are built.
Clear code fixes go into a draft pull request prepared through connected Claude Code or Codex and GitHub, with focused checks. With Figma edit access, corrections can go into the design file. Changes that alter the design come back as options, so the team can decide how the experience should work. Your reviewers merge the code changes.
Consider a fictional signup-form review. The email and password fields have placeholder text but no visible labels, and the hint text is too faint. Mona's returned draft pull request adds the labels and darkens the hint text. The password rules, however, only appear after a failed attempt. She leaves that as an open design decision with two options: display the rules below the field or check them as the person types.
The handoff separates what was found, what changed and what is still open, with each issue's location and related WCAG success criterion. The team can review the concrete form changes while the designer chooses how to present the password rules. Developers get a diff to review, and the designer gets one specific choice to make.
The pass covers the work tested. Full conformance audits, testing with assistive-technology users and legal sign-off remain separate.
Put the right mix to work
For a baseline, start with WAVE or Lighthouse and use Accessibility Insights or axe DevTools when you need guided browser evaluation. Build manual and assistive testing into the work. Add an ongoing platform when the team needs to coordinate findings across repeated releases, and choose a repair route that reaches the files or website layer you intend to change.
For a specific page or release where design and code both need attention, Mona gives your team a concrete review-and-fix pass: clear changes to inspect and design options to resolve. Explore accessibility review with Mona.
