Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.

accessibility-remediation-plan

Installable Ships in accessibility-auditor — or copy the raw skill below.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Accessibility Remediation Plan

Transform an audit report into an actionable, sprint-ready backlog with severity-sequenced delivery across engineering, design, and content teams.

Usage

/accessibility-remediation-plan <audit-report-path> [--format jira|ado|markdown] [--sprints <n>] [--team <name>]

Examples:

  • /accessibility-remediation-plan audit-report.md --format ado --sprints 3
  • /accessibility-remediation-plan findings.md --format jira --team "Frontend Squad"
  • /accessibility-remediation-plan findings.md --format markdown — output as Markdown table

Phase 1 — Ingest and Triage

Read the audit report. For each finding, extract:

  • Finding ID
  • WCAG SC
  • Severity (critical / serious / moderate / minor)
  • Conformance impact
  • Location (component, page, or URL)
  • Estimated effort (XS / S / M / L)
  • Owner type (engineering / design / content / cms-config)

Owner-type classification guide:

Owner type Applies when
engineering Fix requires code change (HTML, CSS, JS, component, template)
design Fix requires a design decision or updated component spec
content Fix can be applied by a content editor in the CMS without code change
cms-config Fix requires a CMS configuration change (field validation, template rule, workflow)

Phase 2 — Quick Wins (Before Sprint 1)

Identify all findings that are:

  • Severity: critical or serious
  • Effort: XS or S
  • Owner: content or cms-config (no deployment required)

List these separately as "Quick Wins — can deploy without a release". Examples:

  • Adding missing alt text to images via the CMS alt field
  • Enabling required alt text validation in the content model
  • Adding lang attribute to page templates
  • Updating link text from "Click here" to descriptive text

Phase 3 — Effort Calibration

Convert effort tags to story points using the team's scale (default: Fibonacci):

Tag Story points What it means
XS 1 One-line fix; < 1 hour
S 2 Simple change in one component; < half-day
M 5 Multi-file change or design iteration required
L 8–13 Complex refactor, new pattern, or architecture decision

Sum total story points per sprint capacity. If --sprints N is provided, distribute findings across N sprints: Sprint 1 = all critical, Sprint 2 = serious, Sprint 3+ = moderate/minor.


Phase 4 — Backlog Generation

Azure DevOps format (--format ado)

For each finding, produce a work item:

## Bug: [A11Y-<ID>] <SC> — <Short description>

**Area Path:** <project>/Accessibility
**Iteration:** Sprint <N>
**Severity:** <1-Critical / 2-High / 3-Medium / 4-Low>
**Priority:** <1–4>
**Tags:** accessibility; wcag-2-2; <sc-number>; <platform>

### Repro steps
1. Navigate to: <URL / component path>
2. <Action — e.g. "Use Tab key to reach the Sign In button">
3. Observe: <actual behaviour — the button is hidden by the sticky header>

### Expected behaviour
<What WCAG requires — e.g. "The focused element must not be entirely hidden by author-created content (SC 2.4.11).">

### Acceptance criteria
- [ ] <Specific testable fix — e.g. "`scroll-padding-top` equals sticky header height">
- [ ] axe-core scan on this page returns 0 violations for this rule
- [ ] Manual keyboard Tab test confirms the element is partially or fully visible when focused
- [ ] Screen reader (NVDA + Chrome) announces the element correctly

### Fix guidance
<Paste the remediation block from the audit finding>

Jira format (--format jira)

## [A11Y-<ID>] Bug: <SC> — <Short description>

**Issue type:** Bug
**Priority:** <Highest / High / Medium / Low>
**Labels:** accessibility, wcag-2-2, <sc-number>
**Sprint:** Sprint <N>
**Story points:** <n>
**Component:** <component name or page>
**Epic link:** Accessibility Remediation Sprint <N>

**Description:**
<Finding description from audit>

**Steps to reproduce:**
1. Go to: <URL>
2. <Action>
3. Observe: <failure>

**Expected result:** <WCAG requirement in plain language>

**Acceptance criteria:**
- <testable criterion 1>
- <testable criterion 2>
- axe-core regression test passes

**Attachments:** <reference the audit finding ID in the audit report>

Phase 5 — Design Backlog (Design-Owner Findings)

For design-owned findings, produce design tickets with specific deliverables:

## Design Task: [A11Y-D-<ID>] <SC> — <Component> needs updated spec

**Deliverable:** Updated Figma/design spec for <component> that:
- Shows focus indicator style meeting SC 2.4.7 (visible, ≥ 3:1 contrast against adjacent colour)
- Documents keyboard interaction model (Tab, Arrow, Enter, Escape behaviour)
- Includes touch target size annotations (minimum 24×24 CSS px per SC 2.5.8)

**Acceptance criteria:**
- [ ] Focus state is designed explicitly (not relying on browser default)
- [ ] All interactive elements show a minimum 24×24 px hit area in the spec
- [ ] Design has been reviewed against WCAG colour contrast (1.4.3, 1.4.11)

Phase 6 — CMS Governance Actions

Group cms-config findings into a CMS Configuration Action Plan — items that the CMS administrator or solution architect implements, not the dev team:

Sitecore XM Cloud

  • Make image Alt field required on all media templates that surface editorial images
  • Add authoring validation: "Page title must be unique" (SC 2.4.2)
  • Configure Sitecore Forms validation: every field requires a Label field (SC 1.3.1)
  • Add Experience Editor guidance text for ARIA label fields on navigation components

Optimizely CMS

  • Enable required Alt text on Image content type
  • Add <fieldset> + <legend> to all radio/checkbox block types in the block editor
  • Optimizely Forms: make Field Name required; add ARIA hint field to form blocks

Umbraco

  • Make Alt text mandatory on Image media type (Umbraco content type property setting)
  • Configure Block List editors to require a Heading property (prevents headingless blocks)
  • Umbraco Members: disable CAPTCHA or configure audio CAPTCHA alternative

Phase 7 — Delivery Summary

Output a sprint plan summary:

## Remediation Delivery Plan

| Sprint | Focus | Findings | Story Points | Owner |
|---|---|---|---|---|
| Quick Wins | Critical/serious content + cms-config | N | N | Content / CMS Admin |
| Sprint 1 | All critical engineering | N | N | Engineering |
| Sprint 2 | All serious engineering + design | N | N | Engineering + Design |
| Sprint 3 | Moderate + minor | N | N | Engineering + Design |
| Ongoing | Content governance | N | — | Content team |

**Projected conformance after Sprint 1:** Partially Supports (critical resolved)
**Projected conformance after Sprint 2:** Partially Supports → Supports (most AA criteria)
**Full WCAG 2.2 AA conformance target:** <date>

Reference

See accessibility-wcag-scan/templates.md for the Finding Record schema used as input.

Technical details
Plugin
accessibility-auditor
Author
Dakota Smith
Skill name
accessibility-remediation-plan
Maturity
experimental
Security review
No security review
Owners
  • design
  • engineering
  • security
Argument hint
<audit-report-path> [--format jira|ado|markdown] [--sprints <n>] [--team <team-name>]
Allowed tools
  • Read
  • Bash(cat *)
  • Bash(ls *)
  • Write
  • Edit
Source
plugins/accessibility-auditor/skills/accessibility-remediation-plan/SKILL.md

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.