Accessibility Testing
axe-core WCAG checks on every page. Severity-ranked findings, ARIA snapshots, ruleset config, and compliance report exports.
Accessibility Testing
AegisRunner runs axe-core on every page during a scan to find accessibility violations against WCAG. The findings show up on the scan result page, on each page's detail panel, and in the dedicated Accessibility tab.
What gets checked
axe-core runs the full ruleset for these standards:
| Standard | What it covers |
|---|---|
| WCAG 2.0 Level A | The minimum requirements: text alternatives, keyboard operability, no flashing content. |
| WCAG 2.0 Level AA | The standard most regulations cite: color contrast, resize-to-200%, focus visibility, descriptive headings. |
| WCAG 2.1 Level A & AA | Adds mobile and cognitive accessibility — orientation, motion-actuated input, status messages. |
| Best practices | Useful patterns that aren't strictly required by WCAG but improve accessibility (e.g. ARIA usage, landmark regions). |
You can scope which rules run from Project Config → AI Config → Accessibility ruleset. Default is WCAG 2.1 AA — the regulatory bar most teams care about.
Where you see findings
Scan result page
The Accessibility tab on the scan result page rolls up findings across the whole site:
- Total violations, by severity (critical, serious, moderate, minor).
- Most-impacted pages.
- Most-frequent rules — useful for spotting systemic issues ("every page has the same color-contrast violation in the footer").
Page detail
Drill into a single page from the Pages tab and you'll see violations specific to that page, with:
- The exact element and its locator.
- The rule it violated, with link to the full axe documentation.
- Severity and impact.
- How to fix it.
Recommendations
Accessibility issues also appear in the project-level Recommendations tab, mixed with SEO, security, and performance findings, and sorted by overall severity.
Severity levels
| Severity | Meaning |
|---|---|
| Critical | Makes the site unusable for some users (no alt text on essential images, missing form labels, broken keyboard navigation). |
| Serious | Significant barriers (low color contrast, missing focus indicators, vague link text). |
| Moderate | Workarounds exist but the experience is degraded (wrong heading order, unclear button purpose). |
| Minor | Best-practice issues that don't directly block users. |
Accessibility snapshots Pro+
Beyond rule-based checks, Pro and above can capture accessibility snapshots — the page's full ARIA tree, the same one a screen reader would read.
Why it matters:
- Auto-heal uses the snapshot to find drifted elements by their accessible name and role rather than CSS classes.
- Test stability — locators built from accessible names survive class renames and refactors.
- Manual review — you can see literally what a screen reader user encounters on each page.
Enable accessibility snapshots in the scan modal under Pro features. They're saved per page and viewable from the page detail.
Running accessibility checks during test runs
Tests can include explicit accessibility-check steps (a11y-check) that run axe at any point in the flow — useful for asserting that a modal doesn't break accessibility, or that a dynamically loaded form is still keyboard-navigable.
By default, the AI generator includes an a11y-check step at the start of each generated test for full coverage. Disable per-test from the test detail page if you want a slimmer suite.
Tuning out specific rules
Some rules might not apply to your site (e.g. you've made an informed decision to use a specific contrast ratio). To exclude rules without disabling all checks:
- Open Project Config → AI Config → Accessibility ruleset.
- Add the rule ID to the exclusion list (e.g.
color-contrast). - Save. The rule is no longer evaluated for this project's scans and tests.
Excluded rules still appear in the audit log so reviewers know what's been turned off.
Common questions
Why is the scan flagging elements that look fine?
axe-core checks the underlying markup, not the visual rendering. A button styled to look correct but built from a <div> with no ARIA role will fail keyboard-operability rules — even though it works for mouse users.
Can I scan only WCAG 2.0 AA, not 2.1?
Yes — restrict to wcag2a,wcag2aa in the ruleset config.
Does this cover Section 508 or EN 301 549?
Both standards align closely with WCAG 2.1 AA, which is our default ruleset. The findings on the Accessibility tab map directly onto the rules each standard requires.
Related
- Starting a New Scan — accessibility toggle in scan modal.
- Understanding Scan Results — Accessibility tab walkthrough.
- Managing Projects — ruleset configuration.