web-accessibility

name	web-accessibility
description	Routing-first skill for web accessibility remediation and verification. Use when the main job is classifying which accessibility surface is failing — semantics, keyboard/focus, labels/announcements, visual perception/reflow, media alternatives, or routed-app navigation feedback — and turning vague audit, WCAG, axe/Lighthouse, or "make this accessible" requests into one concrete remediation packet. Route broad UI critique to `web-design-guidelines`, component API architecture to `ui-component-patterns`, responsive layout strategy to `responsive-design`, and system governance to `design-system`.
allowed-tools	Read Write Bash Grep Glob
compatibility	Best for frontend and fullstack web work where the primary task is accessibility remediation or manual-vs-automated verification. Not for broad UI polish reviews, reusable component API architecture, or viewport-first layout strategy as the main owner.
license	MIT
metadata	{"tags":"accessibility, a11y, wcag, aria, keyboard-navigation, focus-management, screen-reader, frontend","platforms":"Claude, ChatGPT, Gemini, Codex","version":"2.1.0","modernization":"2026-04-13T00:00:00.000Z","hardening":"2026-04-18T00:00:00.000Z","source":"akillness/oh-my-skills"}

Web Accessibility

Use this skill when the job is to name the failing accessibility surface, fix it at the right layer, and leave behind a short remediation + verification packet.

The job is not to dump generic WCAG prose, paste raw scanner output, or absorb every neighboring frontend concern.

This skill should:

1. classify the failing accessibility surface,
2. separate automated findings from manual or assistive-technology follow-up,
3. choose the smallest credible remediation packet,
4. keep routed-app feedback and focus behavior explicit,
5. route broader design/layout/component-governance work honestly.

Read these support docs first:

• references/intake-packets-and-route-outs.md
• references/audit-remediation-checklist.md
• references/handoff-boundaries.md

When to use this skill

• A team says “make this accessible” and the missing accessibility surface is still unclear
• axe, Lighthouse, Accessibility Insights, Pa11y, QA notes, or user reports need to be turned into one remediation plan instead of a raw finding dump
• You need to decide whether the main issue is semantics, keyboard/focus, labels/announcements, reflow/contrast/motion, media alternatives, or routed-app navigation feedback
• A modal, form, nav, menu, table, dashboard, or routed flow needs manual-vs-automated verification guidance before release
• Screen-reader, keyboard-only, or zoom/reflow issues are suspected, but ownership and next checks are unclear

When not to use this skill

• The main task is broad UI polish, heuristic review, hierarchy, or interface consistency → web-design-guidelines
• The main task is reusable primitive / slot / variant API design or component-family ownership → ui-component-patterns
• The main task is viewport adaptation, breakpoint strategy, container-query planning, or layout overflow control → responsive-design
• The main task is token governance, contribution rules, or system-wide frontend standards → design-system
• The task is only to run one tool and paste raw results; run the tool directly, then return here to prioritize remediation and manual follow-up

Instructions

Step 1: Frame the accessibility job before naming fixes