Web
AuraScore 79/100

Design System Accessibility and WCAG Remediation Audit

Conduct a technical accessibility audit on web UI design systems against WCAG standards to remediate compliance defects.

Use this template when evaluating web UI component libraries for keyboard accessibility, ARIA semantics, and screen reader compatibility. It delivers a structured engineering remediation report prioritized by severity.

Template

Role: Principal Accessibility Engineer and Design System Architect specializing in WCAG standards, ARIA authoring practices, and assistive tech compatibility.

Context

  • Design system library: {{design_system_name}}
  • Component library scope: {{ui_component_scope}}
  • Target screen reader & browser pairings: {{assistive_tech_targets}}
  • Compliance threshold: {{wcag_conformance_target}}
  • Critical keyboard navigation defects: {{known_keyboard_blockers}}
  • Theme color tokens: {{color_contrast_standard}}

Task

Author a comprehensive Design System Accessibility Compliance Report for {{design_system_name}}, auditing components across {{ui_component_scope}} and detailing code-level fixes to satisfy {{wcag_conformance_target}}.

Method

  1. Evaluate current DOM structures in {{ui_component_scope}} against WAI-ARIA 1.2 authoring patterns.
  2. Trace focus management behaviors to resolve {{known_keyboard_blockers}} across modal, dropdown, and composite widgets.
  3. Validate semantic markup and live region announcements across {{assistive_tech_targets}}.
  4. Audit {{color_contrast_standard}} across all active UI states (focus visible, active, hover, disabled).
  5. Identify missing accessibility API bindings, incorrect role definitions, and orphaned label elements.
  6. Draft reusable code patches for compound components requiring focus traps or roving tabindex.
  7. Create regression testing recipes combining automated axe-core rules with manual assistive tooling checks.

Constraints

  • MUST reference specific WCAG Success Criteria numbers (e.g., 2.1.1, 4.1.2) for every violation.
  • MUST NOT recommend dropping custom components for unstyled native controls if standard ARIA patterns can resolve the defect.
  • Code examples MUST include both semantic HTML markup and corresponding keyboard interaction handlers.
  • Maintain full consistency with {{color_contrast_standard}} tokens.

Output format

  1. Compliance Status Overview (conformance level summary table)
  2. Component-by-Component Defect Log (Component, Failure, WCAG SC, Remediation snippet)
  3. Focus Management & ARIA Patterns Reference (maximum 3 comprehensive code blueprints)
  4. Automated & Manual QA Verification Protocol (numbered checklist under 300 words)

Self-review

  • Are all {{known_keyboard_blockers}} addressed with specific focus handling patterns?
  • Does every flagged defect map to a verified {{wcag_conformance_target}} clause?
  • Are assistive technology behaviors verified for {{assistive_tech_targets}}?
AuraScore breakdown
79/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-web
technology-software
accessibility
wcag
design-system