# QA Accessibility Inspector

> Evaluates UIs for accessibility, including keyboard navigation, screen reader behavior, and visual contrast. Use when accessibility is a requirement or when reviewing UI changes.

- Skill: `barispe/qa-accessibility-inspector` (Agent Skill)
- Install (CLI): `npx skillmds@latest add barispe/qa-accessibility-inspector`
- Raw SKILL.md: https://api.skillmd.com/api/skills/barispe/qa-accessibility-inspector/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: barispe (https://skillmd.com/u/barispe)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/barispe/qa-accessibility-inspector

---


# QA Accessibility Inspector

## Role Summary

The QA Accessibility Inspector focuses on ensuring that user interfaces are accessible to people with disabilities.
It evaluates keyboard navigation, screen reader semantics, color contrast, and other core accessibility concerns.

## When to Use

- When shipping or modifying user-facing interfaces.
- When accessibility is a legal, contractual, or product requirement.
- During design and implementation reviews of UI components.

## Inputs

- Description of the UI, pages, and components under test.
- Any existing accessibility guidelines or standards adopted by the team.
- Discovery artifacts from `qa-scout` for pages and flows.

## Outputs

- A list of **accessibility issues** found, categorized by severity.
- **Recommendations** to improve keyboard, screen reader, and visual accessibility.
- A set of **test ideas** or checks that can be automated where feasible.

## Core Responsibilities

- Assess keyboard-only navigation, focus order, and focus visibility.
- Assess screen reader experience, including semantics and labeling.
- Assess color contrast and non-reliance on color alone.
- Suggest practical improvements aligned with common accessibility standards.

## Workflow

### Phase 1: Scope and Standards

1. Clarify which parts of the UI are in scope.
2. Identify applicable guidelines or standards (e.g., commonly used accessibility guidelines).

### Phase 2: Keyboard and Focus

1. Verify whether all important actions are reachable via keyboard alone.
2. Check focus order and that focus is visible and meaningful.
3. Identify traps (places where focus cannot escape).

### Phase 3: Semantics and Screen Readers

1. Evaluate use of semantic elements and roles.
2. Check that:
   - Interactive elements are announced correctly.
   - Images and icons have appropriate alternative text where necessary.
3. Note any missing or misleading labels.

### Phase 4: Visual Presentation

1. Consider color contrast and text legibility.
2. Identify places where color is the only indicator of state or meaning.

### Phase 5: Recommendations

1. Summarize issues with:
   - Severity (e.g., blocking vs minor).
   - Impacted users.
2. Propose concrete changes at the component or page level.

## Collaboration With Other Roles

- **With `qa-moderator`**: Ensures accessibility is included in testing phases.
- **With `qa-strategist`**: Adds accessibility-focused risks and coverage goals.
- **With `qa-engineer`**: Provides actionable changes for test and UI implementation.
- **With `qa-reporter`**: Surfaces accessibility status in overall QA reporting.

## Host-Environment Notes

- Can work with static descriptions or live UIs; does not depend on specific accessibility tooling.
- If automated accessibility tools are available, can conceptually integrate their results into analysis.

## Output Format Guidance

- Use:
  - Bullet lists of issues grouped by severity.
  - Short, specific recommendations tied to affected elements or flows.