omh-accessibility-audit
[omh] Hermes Accessibility Audit workflow: prepare WCAG, keyboard, focus, screen-reader, target-size, and reflow evidence gates for UI surfaces. Use when the user says: accessibility-audit, accessibility audit, a11y audit, a11y architect, wcag audit, wcag 2.2, wcag 2.2 aa, accessibility pass.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 2881
- Лиценз
- MIT
- Последна проверка на записа
- 22.09.2026 г.
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add rlaope/oh-my-hermesСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
Accessibility Audit
This is an OMH accessibility-audit workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).
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
omh-frontendfirst. - The user needs rendered layout, screenshot, CJK, or pixel-diff QA rather than accessibility semantics; use
omh-visual-qa. - The user needs a broad premium-quality gate across web, deck, PDF, or posters; use
omh-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.