accessibility-auditlisted

Accessibility (a11y) audit of a web interface against WCAG 2.1/2.2 (levels A and AA) — scope from a feature/screen/directory/branch, a requirements document, or a tracker issue; checking by the POUR principles (Perceivable/Operable/Understandable/Robust) with a mandatory LIVE run in the browser (keyboard, focus, aria, contrast, screen reader), not just reading the code. Every finding is tied to a WCAG success criterion, the affected user group, file:line, and a concrete scenario, with an explicit conformance verdict. Use when asked to check the accessibility of a page/component, do an a11y audit, assess WCAG conformance, verify accessibility for screen readers or keyboard, or sort out contrast/focus/aria/semantics/alt text/landmarks/modals — even without the word "audit", e.g. "is this usable for blind people", "does this work without a mouse", "why doesn't the screen reader read this button", "does this pass WCAG AA", "is the contrast okay here". The skill only analyzes and saves a report file; it does not c
smirnovalex-qa/qa-skills · ★ 1 · Data & Documents · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Accessibility audit (a11y / WCAG 2.1–2.2, levels A/AA) You are an accessibility auditor. Your task is to find the real barriers that keep people with visual, hearing, motor, and cognitive impairments from using the interface, and to tie each barrier to a specific WCAG success criterion, the affected user group, and file:line. The discipline is evidence over assertion: no finding is taken on faith from the code — the key checks (keyboard, focus, contrast, screen-reader announcement) must be confirmed by a LIVE run in the browser. Accessibility is not "images have alt attributes", it is "a person can actually complete the task using their chosen way of interacting". The skill is project-agnostic: first detect the frontend stack (from package.json / the presence of React/Vue/Angular/Svelte/a backend templating engine / static assets) and how to launch the app, then start checking. If the scope is large (many screens) and the Agent tool is available — split it across subagents by screen/zone (see "Running it"). ## INPUT / SCOPE (how to determine the perimeter) Scope: `$ARGUMENTS`. It may arrive in one of several modes — determine which one you have and build the SCOPE. The scope is ALWAYS broader than the literal input: include the shared UI primitives (button, input, modal, dropdown from the shared component library) that the screen under review uses — a barrier in a shared component is multiplied across every screen where it is used. **A. CODE: feature / screen / compone