accessibility-regression-test-planner

Plans risk-based accessibility regression tests across unit, browser, axe, and assistive-technology layers.

Updated Jul 7, 2026
One-click install
npx skills add https://github.com/vmitsaras/Agent-Skills --skill accessibility-regression-test-planner-vmitsaras
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: accessibility-regression-test-planner
Source: https://github.com/vmitsaras/Agent-Skills/tree/main/skills/frontend-a11y/accessibility-regression-test-planner
Command: npx skills add https://github.com/vmitsaras/Agent-Skills --skill accessibility-regression-test-planner-vmitsaras

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams that complete accessibility audits often struggle to decide which findings deserve automated regression tests, which checks must stay manual, and where each check belongs, leading to brittle, duplicated, or coverage-driven test suites. ## Core Features & Use Cases - Layer and method selection: Maps each confirmed finding to the narrowest reliable test layer, from unit and component tests through browser automation, axe integrations, keyboard checks, and visual regression. - Candidate dispositions: Classifies every candidate as covered-existing, automate-now, automate-after-enabler, manual-recurring, or do-not-add, with explicit rationale. - Manual and assistive-technology planning: Defines repeatable procedures, environments, evidence, cadence, and ownership for checks that require human judgment or screen reader smoke tests. - Use Case: After an audit confirms a focus-trap defect in a modal dialog, use this Skill to produce a source-to-coverage map that assigns a component-level keyboard test, a browser focus-restoration check, and a release-cadence screen reader smoke test. ## Quick Start Use the accessibility-regression-test-planner to turn my confirmed audit findings into a regression test plan covering automated and manual checks.

Frequently Asked Questions about accessibility-regression-test-planner

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I plan accessibility regression tests after an audit?▼

Feed confirmed findings with evidence, impact, and retest procedures into the planner. It normalizes each source, groups by root cause, selects the narrowest reliable test layer, and outputs a source-to-coverage map with automated and manual check plans.

Which accessibility checks should be automated versus manual?▼

Automate checks with deterministic, observable failure signals such as role, name, focus movement, and axe-detectable rules. Keep checks requiring human judgment, meaning, or actual assistive-technology output as manual-recurring procedures with defined cadence and ownership.

Can axe alone verify accessibility regression coverage?▼

No. Axe detects rule-based issues in stable states but cannot evaluate keyboard operation, focus logic, announcement quality, or task completion. The plan treats axe as one method scoped near the regression, complemented by keyboard, browser, and manual checks.

When should I not use an accessibility regression test planner?▼

Do not use it when findings are still provisional or unreproduced, when you need the audit itself, or when the goal is raising coverage percentages. Validate findings first, then plan regression coverage only for stable, confirmed contracts.

How do I handle a confirmed accessibility bug that is not fixed yet?▼

Plan the regression check against the agreed corrected behavior and mark implementation as blocked until remediation lands. Never encode the current inaccessible behavior as the expected test result.