a11y-review

Automate structured accessibility reviews of UI changes for keyboard, semantics, labeling, and contrast issues.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/IAG-Patterns/DEMO_COPILOT_SKILLS --skill a11y-review
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: a11y-review
Source: https://github.com/IAG-Patterns/DEMO_COPILOT_SKILLS/tree/main/.github/skills/a11y-review
Command: npx skills add https://github.com/IAG-Patterns/DEMO_COPILOT_SKILLS --skill a11y-review

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill provides a practical, repeatable checklist to systematically identify accessibility gaps in UI changes, focusing on keyboard operability, semantics, labeling, and visual contrast. It helps teams avoid overclaiming accessibility and encourages iterative verification.

Core Features & Use Cases

  • Keyboard readiness: ensure all interactive elements are reachable and operable; focus indicators are visible; no focus traps.
  • Semantics and labeling: prefer native elements; use ARIA only when necessary; ensure controls have accessible names.
  • Contrast and non-color cues: verify adequate contrast; ensure errors and status messages are conveyed without relying on color alone.
  • Manual verification: recommend tools (e.g., Accessibility Insights) and quick screen-reader spot checks for validation.

Quick Start

Review the latest UI changes using the accessibility checklist, validate keyboard operability and focus visibility, inspect semantic usage and labeling, verify color contrast with non-color cues, and perform a quick screen-reader spot check using recommended tools.

Frequently Asked Questions about a11y-review

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

FAQPage Schema
How do I run an accessibility review on my web interface?

Run an accessibility review by applying a structured checklist to UI changes, validating keyboard operability, inspecting semantic HTML and ARIA usage, verifying color contrast, and performing a manual screen-reader spot check.

What is the best way to test keyboard operability and focus visibility in UI changes?

Test keyboard operability by ensuring all interactive elements are reachable and operable, verifying focus traps are absent, and confirming focus indicators remain visible throughout navigation workflows.

How do I check color contrast and non-color cues for accessibility compliance?

Check color contrast by verifying adequate visual contrast ratios, and ensure error or status messages are conveyed with non-color cues so information is accessible without relying on color alone.

Can I use ARIA attributes instead of native HTML elements for accessible controls?

Prefer native HTML elements for accessible controls and use ARIA only when necessary, ensuring all interactive controls have accessible names to support proper screen-reader interaction.

Do I need manual verification tools for a complete a11y review?

Manual verification is required for a complete a11y review, using recommended tools like Accessibility Insights and quick screen-reader spot checks to validate automated findings and ensure reliable outcomes.

When should I avoid automated accessibility testing?

Avoid relying solely on automated accessibility testing when verifying dynamic content, focus traps, or non-color error cues, as these require manual human-in-the-loop verification to prevent overclaiming compliance.