Automated accessibility testing for your website
Mira is an accessibility testing tool that runs a WCAG 2.x A/AA audit as part of the free general site test. Point it at a URL and it checks contrast, ARIA, form labels, heading structure, keyboard navigation, and focus states — then lists the issues so you can fix them in priority order.
No setup, no scripts: the audit runs on the same pages and journeys the testing agent already visits, so accessibility checks come along with the rest of your website health check.
What a website accessibility audit checks, automatically
The audit runs the WCAG 2.1 A/AA success criteria that tools like Axe can check automatically (the wcag2a, wcag2aa, and wcag21aa rulesets) on every page the agent visits. The issues it looks for are the ones automated QA is actually good at finding:
-
Color contrast
Text and UI elements that fail WCAG contrast ratios against their background.
-
ARIA usage
Missing, redundant, or invalid ARIA attributes that confuse assistive technology.
-
Alt text
Images without alternative text, or decorative images that should be hidden from screen readers.
-
Keyboard navigation
Interactions that trap the keyboard or cannot be reached without a mouse.
-
Form labels
Inputs without a programmatically associated label, name, or accessible description.
-
Heading structure
Skipped heading levels that break the document outline for screen-reader users.
-
Focus states
Interactive elements with no visible focus indicator, so keyboard users lose their place.
-
WCAG 2.x A/AA rule violations
Additional success-criteria violations the automated rulesets can detect, reported with the rule that fired.
This is automated accessibility testing against the criteria machines can verify — an automated audit, not a full compliance review. Human judgment is still required for anything it can't measure.
Free as part of the general site test — no setup beyond the URL
Accessibility is one of the built-in audits in Mira's Mode 1 general site test. Give a URL and the agent discovers representative pages and key journeys, then runs the accessibility audit on the pages it visits — giving you a website health check you can act on, no setup beyond the URL.
URL-based, zero configuration
No audit setup, no rule files, no separate crawler to wire up. The accessibility checks ride along with the general test — one URL in, an audit out.
Prioritized, actionable issues
Findings come back as issues you can act on — what failed, where, and which WCAG rule it violates — so you fix the highest-impact problems first instead of reading a raw report.
How it works: the audit covers representative pages and key journeys — the pages agents discover and select — not an exhaustive crawl of your whole application, and not pages behind authentication. See the agentic end-to-end testing guide for how agents discover and test those journeys.
Why run WCAG accessibility testing alongside functional checks
Most automated testing tools stop at functional regressions: they verify that buttons click and forms submit, and never look at whether a screen-reader user can reach them. An automated accessibility audit catches the other half — the issues that stop assistive technology users, and often crossover customers, from completing the journey at all.
The audit runs against the same pages as the rest of the test, so accessibility issues surface in the same report as broken journeys.
Teams working toward an ADA compliance check or a Web Content Accessibility Guidelines program use automated results to prioritize the fixes an auditor would flag first.
Automated results are one input for an accessibility program — they are not a WCAG certification and do not establish legal compliance on their own.
One honest caveat that applies to every AI testing agent: findings are model-assisted and can be wrong, and because the audit samples representative pages and key journeys, a clean accessibility run is a useful signal — not a WCAG certification. Treat the report as strong evidence to act on, then verify against the real pages.
Frequently asked questions
- Is the accessibility audit a WCAG certification?
- No. It is an automated accessibility audit against the WCAG 2.1 A/AA success criteria that tools like Axe can check automatically. Automation can't judge everything a human auditor can, so a clean run is a useful signal — not a WCAG certification.
- Which pages does the audit cover?
- The pages the agent visits during the general site test: representative pages and key journeys it discovers and selects. It does not crawl your whole application and does not reach pages behind authentication.
- Does the audit cover pages that require login?
- No. Authenticated areas sit outside the automated accessibility audit, because the agent tests the pages it can reach with the URL you provide. Use a targeted workflow test if a specific authenticated journey must be checked.
- Does a clean audit mean my site is accessible?
- Not on its own. Automated checks catch a meaningful subset of WCAG issues, but accessibility also requires human review. Because the audit samples representative pages and key journeys — and findings are model-assisted — treat a clean run as strong evidence, not a guarantee.
- Does Mira promise legal compliance like an ADA compliance check?
- No. Mira runs automated accessibility testing; it does not provide legal advice and does not certify compliance with the ADA or any other law. Automated results are an input to an accessibility program, not a legal determination.
Run a free automated accessibility audit
Give Mira a URL and the accessibility audit runs as part of the general site test — no setup. See how the two testing modes work and how the audit fits into agentic end-to-end testing.
Try Mira