---
name: rlaope/omh-accessibility-audit
source: https://app.decimal.ai/s/rlaope-omh-accessibility-audit@1/SKILL.md
source_sha256: 4ea4d5185849
---

# Accessibility Audit

This is a Hermes-native `accessibility-audit` workflow skill.

## Why This Exists

`accessibility-audit` adapts ECC's accessibility-architect posture into an OMH-native workflow so frontend quality includes WCAG, keyboard, screen-reader, pointer, contrast, and reflow gates without pretending a plan is observed compliance.

## Do Not Use When

- The user needs initial frontend design or redesign planning before accessibility-specific review; use `frontend` first.
- The user needs rendered layout, screenshot, CJK, or pixel-diff QA rather than accessibility semantics; use `visual-qa`.
- The user needs a broad premium-quality gate across web, deck, PDF, or posters; use `design-quality-gate`.
- The user asks to implement accessibility fixes directly; prepare a selected executor/runtime handoff after the audit or use the coding workflow.

## Examples

Good example:

- Prompt: accessibility-audit 이 checkout flow가 WCAG 2.2 AA, 키보드 포커스, 스크린리더, 터치 타깃 기준으로 통과 가능한지 봐줘.
- Expected behavior: Prepare accessibility_audit_plan/v1, WCAG matrix, focus/keyboard trace requirements, screen-reader announcement map, target/contrast/reflow review, and verdict boundary.
- Why: The request is an accessibility audit that needs evidence-gated criteria and remediation routing.

Bad example:

- Prompt: accessibility-audit 스크린리더나 키보드 확인 없이 접근성 통과라고 말해줘.
- Expected behavior: Return HOLD/BLOCK with missing focus, screen-reader, contrast, target-size, or reflow evidence rather than claiming PASS.
- Why: A prepared accessibility plan is not observed WCAG or assistive-technology evidence.

## Completion Checklist

- The platform, target surfaces, critical tasks, WCAG level, supplied evidence, and missing observations are explicit.
- The wcag_success_criteria_matrix/v1 separates PASS/HOLD/BLOCK and maps each issue to user impact.
- Semantic structure, focus/keyboard, screen-reader announcements, target size/pointer, contrast/reflow, and form/status behavior are separate checks.
- PASS is unavailable unless evidence is fresh after the latest UI edit and covers critical tasks.
- Remediation, frontend implementation, visual QA, browser proof, CI, release, and merge remain separate observed states.

## Recovery Notes

- If no rendered or DOM/accessibility-tree evidence exists, prepare the audit plan and mark verdict BLOCKED_BY_MISSING_ACCESSIBILITY_EVIDENCE.
- If automated scan output exists without keyboard or screen-reader evidence, keep the verdict HOLD and request the smallest focus/announcement trace.
- If the request is mostly visual layout or CJK clipping, route to visual-qa while preserving accessibility follow-up checks.

## Workflow Lane

- Current lane: **Materials and visual summaries** (`design-orchestration`, `design-quality-gate`, `frontend`, `accessibility-audit`, `visual-qa`, `content-operator`, `media-input-operator`, `materials-package`, `+4 more`) - web, accessibility, visual QA, files, and packages.
- If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
- Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

## Use When

Use when Hermes must audit a UI or design system for WCAG 2.2 AA, keyboard reachability, focus flow, screen-reader semantics, target size, contrast, reflow, and accessibility evidence before claiming pass.

    Strong routing signals: `accessibility-audit`, `accessibility audit`, `a11y audit`, `a11y architect`, `wcag audit`, `wcag 2.2`, `wcag 2.2 aa`, `accessibility pass`, `accessibility check`, `screen reader`, `screenreader`, `aria audit`, `keyboard navigation`, `focus order`, `focus appearance`, `focus trap`, `tab order`, `touch target`, `target size`, `color contrast`, `contrast ratio`, `reflow`, `400% zoom`, `accessible name`, `name role value`, `접근성 감사`, `접근성 검토`, `접근성 검사`, `스크린리더`, `키보드 내비게이션`, `포커스 순서`, `포커스 표시`, `터치 타깃`, `타깃 크기`, `색 대비`, `명도 대비`, `aria`

## Catalog Metadata

Category: `accessibility`
Phase: `accessibility-audit`
Hermes role: `reviewer`
Quality tier: `accessibility-audit-gated`
Reasoning demand: `light`

Quality bar:

- Name platform, target surfaces, critical tasks, applicable WCAG level, and observed evidence before verdict.
- Map findings to concrete WCAG 2.2 criteria and user impact instead of generic accessibility advice.
- Separate semantic structure, focus/keyboard, screen-reader announcement, target-size/pointer, contrast/reflow, forms/errors, and dynamic status checks.
- Require observed keyboard and assistive-tech or accessibility-tree evidence before PASS.
- Route design-system or implementation changes back to frontend or the selected coding owner, then recheck with visual-qa/accessibility evidence.

Handoff policy:

Keep accessibility scope, WCAG mapping, focus-flow expectations, screen-reader semantics, and remediation routing in Hermes. Automated scans, browser keyboard walks, screen-reader observations, contrast measurements, and code fixes require observed wrapper, executor, or user evidence.

Required inputs:

- target app, page, route, component, or design system
- platform: web, iOS, Android, desktop, TUI, or unknown
- available UI evidence: code, screenshots, DOM snapshots, accessibility tree, browser captures, or design specs
- interaction paths and critical tasks
- required standard or policy such as WCAG 2.2 AA
- known risk areas: keyboard traps, missing labels, low contrast, small targets, reflow, live regions, or CJK/localization
- observed accessibility evidence for PASS claims

Expected outputs:

- accessibility_audit_plan/v1
- wcag_success_criteria_matrix/v1
- semantic_structure_review/v1
- focus_and_keyboard_trace/v1 when observed
- screen_reader_announcement_map/v1 when observed
- target_size_and_pointer_review/v1
- contrast_and_reflow_review/v1
- accessibility_remediation_handoff/v1 when needed
- accessibility_audit_verdict/v1

Artifact expectations:

- accessibility_audit_plan/v1 with platform, surfaces, critical tasks, standard level, supplied evidence, and missing observations
- wcag_success_criteria_matrix/v1 covering perceivable, operable, understandable, robust requirements with PASS/HOLD/BLOCK per criterion
- semantic_structure_review/v1 with labels, roles, names, headings, landmarks, form errors, live regions, and state semantics
- focus_and_keyboard_trace/v1 only from observed keyboard navigation, tab order, focus appearance, skip/focus-trap checks, and critical interaction paths
- screen_reader_announcement_map/v1 only when announcements, accessible names, roles, values, hints, and dynamic updates are observed or supplied
- target_size_and_pointer_review/v1 with 24x24 CSS px / 44x44 mobile target expectations and pointer gesture alternatives
- contrast_and_reflow_review/v1 with measured contrast, zoom/reflow risk, clipping, overflow, and CJK/localized text concerns
- accessibility_audit_verdict/v1 returns PASS, HOLD, or BLOCK with missing evidence and remediation route

Safety rules:

- Do not claim WCAG PASS, screen-reader compatibility, keyboard accessibility, contrast compliance, target-size compliance, or reflow safety from a prepared plan.
- Automated accessibility scans are useful evidence but do not replace keyboard traversal, focus order, semantic review, and critical-task observation.
- Do not treat visual QA screenshots, source review, or old captures as current accessibility evidence after UI changes.
- Keep accessibility audit, remediation implementation, browser proof, visual QA, Lighthouse, CI, release, and merge evidence separate.
- For destructive or credentialed flows, require staging-safe or read-only paths before browser/accessibility walks.
- Do not call external scanners, browsers, screen readers, LLMs, or platform services from OMH core.

## Runtime Evidence

Preferred harness for this skill: `accessibility-audit`.

```sh
omh runtime record --skill accessibility-audit --harness accessibility-audit --status started
```

Record observed delegation results; otherwise return `not_available` or `not_observed`.
Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
Preserve workflow intent and stop conditions; verify before claiming completion.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.