zivtech Accessibility Role Audit
Review a component, page, or design from the responsibility perspective of specific team roles. Each role brings a distinct vantage point with explicit blind spots — what it CAN see and what it CANNOT. Running multiple roles catches barriers that no single role would find alone.
Relationship to Other Skills
| Skill | Dimension | Question |
|---|---|---|
a11y-critic |
Design decisions | "Is the accessibility approach sound?" |
perspective-audit |
Access methods | "Who is blocked?" (users with disabilities) |
a11y-role-audit (this) |
Team responsibilities | "Who on the team owns preventing/fixing this?" |
These three are complementary layers:
- Critic identifies design gaps
- Perspective audit identifies impact on specific user groups
- Role audit identifies which team member is responsible and what each sees from their vantage point
When to Use
Mode 1: Design Review (before code)
Run visual-design + ux-design lenses over mockups, wireframes, or design specs. Catches accessibility barriers before implementation hardens them.
/a11y-role-audit design <target> [--roles visual-design,ux-design]
Mode 2: Implementation Review (after code)
Run all roles (or a subset) over implemented code. Each lens reviews from its domain-specific vantage point.
/a11y-role-audit code <target> [--roles all]
/a11y-role-audit code <target> [--roles front-end-development,content-authoring]
Mode 3: Finding Attribution (post-critic)
After a11y-critic or perspective-audit produces findings, attribute each to the responsible ARRM role using the decision tree.
/a11y-role-audit attribute <findings>
The 6 Roles
| # | Role | Focus | Primary ARRM Tasks |
|---|---|---|---|
| 1 | Visual Design | Contrast, zoom, focus indicators, targets, motion, forced-colors | 30 |
| 2 | UX Design | Patterns, focus order, error flows, state, consistency, timing | 96 |
| 3 | Front-End Development | Semantic HTML, ARIA, keyboard, live regions, CSS a11y | 90+ |
| 4 | Content Authoring | Alt text, headings, links, captions, language, labels | 42 |
| 5 | Business Analysis | CAPTCHA, time limits, error prevention, requirements | 1 |
| 6 | Testing | AT validation, regression, coverage gaps | 0 (verification) |
Steps
Step 1 — Determine mode and roles
Parse the invocation to identify:
- Mode:
design,code, orattribute - Target: file path(s), URL, or findings to attribute
- Roles: specific roles requested, or
all(default: all)
If mode is attribute, skip to Step 5.
Step 2 — Read reference materials
Read the role definitions for each requested role:
roles/<role-name>.md— perspective, blind spots, checklist, WCAG criteria
Read the ARRM mapping:
roles/arrm-task-mapping.yaml— SC-to-role routing for attribution
Step 3 — Read the artifact under review
Read all source files relevant to the requested roles. For design mode, this may be mockup descriptions, Figma exports, or wireframe specs. For code mode, read HTML/CSS/JS/template files.
Step 4 — Run per-role review
For each requested role, evaluate the artifact through that role's lens:
- Work through the role's review checklist (from the role definition file) item by item.
- For each checklist item:
- PASS — implementation satisfies the criterion. Note evidence briefly.
- FINDING — gap identified. Generate a finding (Step 6 format).
- N/A — criterion doesn't apply to this artifact.
- After the checklist, consider the role's blind spots — flag any areas where a different role's review would be needed.
Step 5 — Attribution mode (for existing findings)
For each finding in the input:
- Identify the WCAG SC referenced
- Look up the SC in
roles/arrm-task-mapping.yaml - Apply the decision tree (first matching rule wins)
- Tag the finding with primary and secondary responsible roles
Step 6 — Output format
## Role Audit Results
### [Role Name]
**Items reviewed**: [count from checklist]
**Findings**: [count]
**Blind spots flagged**: [list of areas needing other roles]
#### Findings
1. **[Severity]**: [Description]
- **Evidence**: [file:line or observed characteristic]
- **WCAG**: [SC number — criterion name]
- **Role ownership**: Primary: [this role] | Secondary: [other role]
- **Fix**: [Recommended action within this role's domain]
#### Blind Spot Escalations
- [ ] [Area] → needs review from [other role]
Severity Calibration
| Severity | When to apply |
|---|---|
| CRITICAL | Blocks access entirely for a user group — no workaround exists |
| MAJOR | Significant barrier — degraded experience with difficult workaround |
| MINOR | Usability degradation — workaround exists and is reasonable |
| ENHANCEMENT | AAA criterion or best practice beyond AA compliance |
Cross-Role Synthesis
After all requested roles complete, produce a synthesis section:
## Cross-Role Synthesis
### Coverage Map
| WCAG SC | Visual | UX | Front-End | Content | Business | Testing |
|---------|--------|-----|-----------|---------|----------|---------|
| [SC] | PASS | — | FINDING | N/A | — | — |
### Gaps Requiring Multi-Role Collaboration
- [Description of gap that spans roles, with roles needed]
### Unreviewed Areas
- [Areas that no requested role covers — suggest which role to add]
Evidence Requirements
- CRITICAL/MAJOR findings: file:line reference required (code mode) or specific design element reference (design mode)
- All findings: WCAG SC citation required
- Assertions without evidence are not findings — they are hunches. Mark them
[UNVERIFIED]and note what evidence would confirm them.
Integration with Workflow
In the full a11y-workflow lifecycle:
scout → plan → [ROLE AUDIT: design mode] → critique plan → implement → test → [ROLE AUDIT: code mode] → critique implementation → [perspective audit]
The role audit runs at two points:
- After planning (design mode) — catches role-specific gaps before implementation
- After testing (code mode) — produces role-attributed findings for targeted fixes