# How the Accessibility Auditor Ensures WCAG Compliance Across Implementations
> Ensure WCAG compliance with our accessibility auditor's three-stage workflow combining automated scanning, assistive tech testing, and manual inspection for robust accessibility.
- Repository: [Michael Sitarzewski/agency-agents](https://github.com/msitarzewski/agency-agents)
- Tags: how-to-guide
- Published: 2026-03-09
---
**The accessibility auditor ensures WCAG compliance by executing a three-stage workflow that combines automated scanning, real-world assistive-technology testing, and manual inspection to cover every WCAG 2.2 success criterion.**
The `msitarzewski/agency-agents` repository defines a specialized **Accessibility Auditor** agent that moves beyond superficial tool scores to deliver rigorous, standards-based accessibility validation. According to the specification in [`testing/testing-accessibility-auditor.md`](https://github.com/msitarzewski/agency-agents/blob/main/testing/testing-accessibility-auditor.md), the auditor follows a disciplined protocol that targets WCAG 2.2 AA (and AAA where required) across all four POUR principles—Perceivable, Operable, Understandable, and Robust.
## Three-Stage WCAG Compliance Workflow
The accessibility auditor structures every engagement around three distinct phases, ensuring that neither automated false positives nor manual oversight gaps compromise the final assessment.
### Stage 1: Stand-Alone WCAG Evaluation
The auditor begins by explicitly targeting WCAG 2.2 success criteria, checking each against the four POUR principles. During this phase, the auditor documents the exact success-criterion reference (e.g., 1.4.3 Contrast Minimum, 4.1.2 Name, Role, Value) for every finding, creating a traceable audit trail from issue to standard.
### Stage 2: Assistive-Technology Testing
Recognizing that automated tools catch only a fraction of accessibility barriers, the auditor conducts real-world assistive-technology sessions. This includes screen-reader checks using **VoiceOver**, **NVDA**, and **JAWS**, as well as keyboard-only navigation trials, voice-control testing, high-contrast mode verification, reduced-motion preference checks, and zoom-level stress tests up to 400%.
### Stage 3: Manual "What-Automation-Misses" Review
The final stage involves manual inspection of elements that automated scanners cannot reliably evaluate. The auditor verifies focus order, logical reading order, ARIA usage on custom components, live-region announcements, and cognitive-accessibility aspects such as plain language and clear error-recovery pathways.
## Critical Rules and Standards Enforcement
Throughout the workflow, the accessibility auditor obeys strict rules that enforce honest, standards-based assessment. The auditor **never relies solely on automated tool scores**, always preferring semantic HTML over ARIA when possible, and documenting every issue with its specific WCAG reference rather than generic descriptions. These constraints ensure that remediation efforts address actual user barriers rather than superficial metric improvements.
## Structured Audit Reporting
The final deliverable is a structured markdown report that lists each issue with its WCAG reference, severity level, user impact, and concrete remediation code snippets. The report format follows a strict template defined in [`testing/testing-accessibility-auditor.md`](https://github.com/msitarzewski/agency-agents/blob/main/testing/testing-accessibility-auditor.md):
```markdown
### Issue 1: Missing accessible name on search button
**WCAG Criterion**: 4.1.2 Name, Role, Value (AA)
**Severity**: Critical
**User Impact**: Screen-reader users hear "button" with no context, cannot determine purpose.
**Current State**:
```html
```
**Recommended Fix**:
```html
```
```
## Automated Baseline Scans
While manual testing forms the core of the audit, the accessibility auditor uses automated tools to establish a baseline before deep inspection. Typical commands include running **axe-core** against local instances and generating Lighthouse accessibility reports:
```bash
# Run axe-core against all pages
npx @axe-core/cli http://localhost:8000 --tags wcag2a,wcag2aa,wcag22aa
# Run Lighthouse accessibility audit
npx lighthouse http://localhost:8000 --only-categories=accessibility --output=json
```
These automated scans provide a starting point for the manual review but never constitute the final compliance determination.
## Summary
- The accessibility auditor follows a **three-stage workflow**: stand-alone WCAG evaluation, assistive-technology testing, and manual inspection.
- Testing covers **WCAG 2.2 AA** (and AAA where required) across all four POUR principles using VoiceOver, NVDA, JAWS, keyboard navigation, and cognitive checks.
- The auditor **never relies solely on automated tool scores**, preferring semantic HTML and documenting exact WCAG references for every finding.
- Final deliverables include **structured markdown reports** with severity ratings, user impact descriptions, and concrete code remediation snippets.
## Frequently Asked Questions
### What WCAG version does the accessibility auditor target?
The accessibility auditor explicitly targets **WCAG 2.2 Level AA** compliance, expanding to Level AAA criteria when project requirements demand higher accessibility standards. This targeting covers all four POUR principles: Perceivable, Operable, Understandable, and Robust.
### Which assistive technologies does the auditor test with?
The auditor conducts real-world testing with **VoiceOver** (macOS/iOS), **NVDA** (Windows), and **JAWS** (Windows) screen readers. Beyond screen readers, the protocol includes keyboard-only navigation, voice-control trials, high-contrast mode verification, reduced-motion preference checks, and 400% zoom stress tests.
### How does the auditor handle automated vs. manual testing?
The auditor uses automated tools like **axe-core** and **Lighthouse** only for baseline scanning, never as final compliance proof. The core workflow emphasizes manual inspection of focus order, ARIA usage, live-region announcements, and cognitive accessibility aspects that automated scanners cannot reliably evaluate. The auditor always prefers semantic HTML over ARIA and documents exact WCAG references for every finding.
### What does the final audit report include?
The final deliverable is a structured markdown report where each issue entry contains the specific **WCAG criterion reference** (e.g., 4.1.2 Name, Role, Value), **severity level**, detailed **user impact** description, the **current non-compliant code**, and **concrete remediation code snippets** showing exactly how to fix the barrier.