Skip to main content

Choosing the Right Accessibility Tool

TestMu AI Accessibility Testing spans browser DevTools, web automation, scheduled and Web Scanner scans, native mobile (manual and Appium), reports, checklists, and optional AI/MCP workflows. Use this page as a router: match your situation to a starting doc, then follow the linked guides for setup and onboarding.

If you are new to the product, read Getting Started with Accessibility Testing first—it lists every major path in one place.

Quick decision table​

I need to…Start here
Manually scan a website in the browserAccessibility DevTools (Overview)
Run accessibility inside Selenium/Cypress/Playwright/etc.Accessibility Automation (Overview) → your framework doc
Schedule recurring scans inside Accessibility (sitemap/CSV/crawler)Test Scheduling - Sitemap (Overview)
Run scans from the Web Scanner productGetting Started with Web Scanner → Starting an Accessibility Scan with Web Scanner
Manually test a native app on a real deviceAccessibility App Scanner (Overview)
Get accessibility from Appium codeNative App Automation Appium (Overview)
Author mobile flows in KaneAI with scansKaneAI Mobile App Testing
Read dashboards, exports, and triageNavigating the Dashboard
See what automation covers vs manual gapsWeb · iOS · Android checklists
Use AI or MCP for analysisAccessibility MCP Server (accessibility-only) vs TestMu AI MCP Server (platform-wide)

Scheduling vs Web Scanner: Test Scheduling is the Accessibility-native recurring flow. Web Scanner is a separate product for URL-based scans. If you are unsure, compare Accessibility DevTools (Overview) (product boundary) and Test Scheduling product boundary.

Use DevTools when​

Start: Accessibility DevTools (Overview) → Install Toolkit if you have not installed the extension yet.

Use Automation when​

  • you want accessibility checks inside automated test runs (CI/CD, nightly builds)
  • you need regression coverage tied to the same suite as functional tests
  • you use a supported web stack on the grid

Hub doc: Automating Accessibility Testing with Selenium (Chrome/Edge, capabilities, lambda-accessibility-scan hook vs accessibility.autoscan).

Framework-specific entry points:

Configuration and pipeline:

Use Test Scheduling when​

  • you want recurring site scans without opening DevTools each time
  • you need sitemap, CSV, or crawler-driven URL discovery
  • you want the Accessibility-native scheduling surface—not the Web Scanner app

Start: Test Scheduling - Sitemap (Overview).

Common next steps:

Advanced URL grouping: If hash-based routes should split issues, enable Fragment Identifier in DevTools settings (web URL grouping context).

Use App Scanner (Manual) when​

  • you are validating native Android or iOS screens interactively
  • you want to inspect issues screen by screen on real devices without Appium

Start: Accessibility App Scanner (Overview).

Contrast with automation: Native App Automation Appium (Overview) · Appium TestNG · Appium WebdriverIO.

Use Native App Automation when​

  • you already run Appium for mobile functional tests
  • you want lambda-accessibility-scan checkpoints and dashboard reports from those runs

Start: Native App Automation Appium (Overview).

Tags: Tag Support for Accessibility Scans when you need scan metadata across runs.

Use Web Scanner when​

  • you are already inside the Web Scanner product
  • you want URL-based accessibility scanning from that workflow (wizard, scheduling tab, etc.)
  • you do not need DevTools or framework automation to start

Start: Getting Started with Web Scanner → Starting an Accessibility Scan with Web Scanner.

Also useful: Adding URLs · Scheduling Options · Advanced Features.

Use KaneAI when​

  • you are authoring a mobile test in KaneAI (not maintaining raw Appium projects)
  • you want to insert accessibility scan steps inside the authored flow

Start: KaneAI Mobile App Testing.

Use Reports when​

  • you need the dashboard, issue breakdowns, exports, or ticketing handoff after any scan type

Core flow: Navigating the Dashboard → Issue Summary → All Issues (reports may also surface Accessibility Web Score when enabled).

Sharing and tracking:

Use Features (product options) when​

  • you need hide/restore, AI issue detection, PDF scans, screenshots, tags, fragment identifiers, analytics widgets, or deep remediation guidance alongside reports

In the sidebar, Features is grouped as Web, Mobile, and Common (same order as below).

Web​

Mobile​

Common​

Use Screen Reader testing when​

  • you must validate behavior with assistive technology (not only automated rules)

Hub: Screen Reader Overview.

By platform:

Pair screen reader sessions with Keyboard Scan for keyboard-only coverage on web.

Use Checklists and Rule References when​

  • you need to know which WCAG-aligned rules automation covers per platform
  • you want the manual test checklist (beyond automated rules) in one glance
  • you need rule-level remediation text

Checklists: Web · iOS · Android.

Rule repositories: Web · Android · iOS.

Compliance framing (not legal advice): Accessibility Compliance Guide · VPAT Report Generation.

Use Accessibility MCP Server when​

  • you want AI-assisted accessibility analysis through an MCP-compatible client, scoped to Accessibility workflows

Doc: Accessibility MCP Server.

Not the same as installing the full multi-tool MCP stack: use Introducing TestMu AI MCP Server for platform-wide MCP setup, then return here for accessibility-specific usage.

Last updated on

Test across 3000+ combinations of browsers, real devices & OS.

Book Demo

Help and Support

Related Articles

On this page