accessibility-skills

ARRM-based accessibility role audit — responsibility-based review lenses

Deep accessibility review from 7 access perspectives — activated by escalation from a11y-planner or a11y-critic when one or more perspectives are flagged at MEDIUM or HIGH alarm level.

ARRM-based accessibility role audit — runs responsibility-based review lenses (visual design, UX design, front-end dev, content authoring, business analysis, testing) to produce role-attributed findings. Complements the access-method perspectives in perspective-audit.

Orchestrate the a11y accessibility lifecycle: scout → plan → critique → [perspective audit] → test → critique. Dual-mode: full lifecycle automation or step-by-step dispatch. Spawns specialist agents at depth-1 from the main session.

Use when you know what component, flow, or interface you need but not yet the right accessibility approach. Best for turning WCAG 2.2 requirements into an accessible implementation plan with WAI-ARIA APG patterns before code hardens bad interaction and state patterns.

Use when you know what component, flow, or interface you need but not yet the right accessibility approach. Best for turning WCAG 2.2 requirements into an accessible implementation plan with WAI-ARIA APG patterns before code hardens bad interaction and state patterns.

Evaluate a Drupal accessibility patch end-to-end: baseline evidence, patch hygiene, after-patch verification, manual/AT checks, critic gate, and upstream handoff. Evidence-gated — never VERIFIED without before/after proof under the same conditions.

How to verify changes in this prompt-only repo: reproduce committed evidence-harness recipes from scratch, don't re-run CI. Covers the evals/results/* harness pattern.

Load this skill whenever you are filing, reviewing, or generating accessibility bug reports — whether from automated tool output, manual testing, or AI agent scans. The purpose of this skill is to make accessibility errors easier to report accurately, so that developers can reproduce, understand, and fix them without additional back-and-forth. Absolutely always include the required fields (URL, XPath, HTML snippet, WCAG SC, rule ID, severity, frequency) in every report. Under no circumstances file a vague report that omits the failing element, the WCAG criterion, or the steps to reproduce.

Use when you have an existing component, flow, or interface and need an evidence-backed accessibility design review after basic checks pass. Best for WCAG 2.2 compliance, focus management, ARIA pattern quality, semantics, and state communication gaps automated tools miss.

Use when you need to run real accessibility tests — Playwright keyboard interactions, axe-core scanning, visual regression, and WCAG 2.2 compliance checks. The measurement layer that feeds evidence into a11y-critic reviews.