Does your page pass automated accessibility checks for WCAG 2.2 Level AA?
Axe-core detects accessibility violations that double as broken semantic signals for AI agents.
What this signal tests
We render your page in a headless browser, inject axe-core (Deque's open-source accessibility engine), and run its full WCAG 2.0/2.1/2.2 Level A and AA ruleset. Axe covers roughly 30 to 40 percent of WCAG criteria that machines can decide automatically. We pass the signal when there are zero critical and zero serious violations; moderate and minor issues do not fail the check but are reported.
Why it matters for your visibility in AI
Accessibility violations are also AI ingestion failures. The axe rules that catch missing image alt text, unlabelled form inputs, buttons with no accessible name, and missing landmark roles are exactly the semantic signals AI agents rely on to read and act on your page. If your image of a product has no alt text, multimodal models can describe it but search-only models cannot. If your form input has no label, an agent trying to fill in your contact form does not know which field is which and fails the task. The same fixes that make your site accessible to screen-reader users make it parseable to LLMs and reliable for agent browsers. This is one of the highest-leverage signals in the catalog: a single audit pass typically resolves dozens of human and machine readability issues at once.
Pass criteria at a glance
| Criterion | Passes when |
|---|---|
| Zero critical AND zero serious violations. |
How we test it
We load your page in a headless Chromium instance, inject the axe-core script, and call axe.run() with the wcag2a, wcag2aa, wcag21a, wcag21aa, and wcag22aa rule tags enabled. Axe returns a list of violations classified by impact: minor, moderate, serious, or critical. We pass the signal when both the critical and serious counts are zero. The full report (including moderate and minor findings) is included in the result for your reference.
Show technical detection method
Render in headless browser; inject axe-core; run axe.run() with wcag2a/wcag2aa/wcag21a/wcag21aa/wcag22aa tags; weight by impact (critical/serious/moderate/minor).
If your site fails: how to fix it
- Install axe DevTools (free Chrome/Firefox extension) and run it on your most important pages - homepage, key landing pages, contact form. The extension lists violations with element selectors and remediation guidance.
- Fix the most common high-impact issues first: add alt attributes to every img tag, add explicit label elements (or aria-label) to every form input, ensure every button and link has accessible text, and check colour contrast for body text against background.
- Add proper landmark roles or HTML5 elements: <header>, <nav>, <main>, <footer>. Each page should have one and only one <main>. These give AI agents and screen readers a structural map of your page.
- Ensure all interactive elements (buttons, links, form fields) have unique, descriptive accessible names. Avoid Click here, Read more, and unlabelled icon buttons.
- Integrate axe-core into your CI pipeline (axe-core, pa11y, or Lighthouse accessibility audits) so regressions are caught before they reach production.
- Re-run the AI Ready Test once critical and serious violations are resolved; moderate and minor issues remain valuable to address but do not block this signal.
Quick facts
| Maturity | ESTABLISHED |
|---|---|
| Weight | high |
| Category | Performance |
Primary sources
Related signals
Frequently asked questions
Will fixing this also improve my Google ranking?
Indirectly, yes. Google uses many of the same signals (semantic HTML, alt text, link text) for its index, and accessibility issues now appear in Search Console reports. More directly, fixing accessibility improves the user-experience metrics (bounce rate, completion rate) that feed ranking.
Does axe catch everything?
No. Axe covers the 30 to 40 percent of WCAG that machines can decide automatically. Issues like meaningful alt text quality, keyboard-trap logic, or content that requires understanding still need manual review by a human auditor.
How long does this take to fix?
Varies widely. A small static site may have zero violations or a handful that take an afternoon. A complex application can have hundreds and require a multi-week audit. Start with the critical and serious issues - those are usually a few dozen and have the biggest impact.
Is this required by law?
In many jurisdictions, yes. The European Accessibility Act, the US ADA (as applied to public-facing websites by recent DOJ guidance), and Section 508 for federal contractors all reference WCAG 2.1 or 2.2 Level AA as the technical standard. Beyond legal risk, the signals also drive AI visibility.
Should I use axe, Lighthouse, or pa11y?
All three use axe-core under the hood. Axe DevTools is the most thorough for interactive auditing; Lighthouse integrates into Chrome DevTools and CI; pa11y is the standard for command-line and CI use. Pick whichever fits your workflow - the underlying rule coverage is similar.
Run your own scan
Run a free scan and see how your site grades across all 155 AI-readiness signals.