# Accessibility Review

## Purpose

Improve inclusive usability by checking whether interfaces are operable, understandable, and robust for people using different devices, input methods, and assistive technologies.

## When to use

- Reviewing or implementing user-facing UI
- Checking forms, dialogs, navigation, or interactive states
- Improving keyboard support, semantics, contrast, or feedback
- Raising the quality bar for long-lived interface patterns

## Inputs to gather

- Relevant screens, components, and interaction flows
- Existing design system, semantic patterns, and accessibility goals
- Keyboard, screen reader, focus, contrast, and motion considerations
- Known constraints in the stack or component library

## How to work

- Check the main user path with keyboard and semantics in mind first.
- Review labels, focus order, state announcements, contrast, and error clarity.
- Prioritize issues that block task completion or create major confusion.
- Recommend changes that fit the current implementation model and team capacity.
- Treat accessibility as product quality, not a final polish pass.

## Output expectations

- Clear accessibility findings or implementation guidance
- Prioritized fixes by impact on usability and inclusion
- Notes on what was inspected directly versus inferred

## Quality checklist

- Findings focus on real interaction barriers.
- Recommendations are specific enough to implement.
- The review covers both semantics and user experience.
- High-impact accessibility gaps are surfaced early.

## Handoff notes

- Mention whether checks were code-based, visual, or manually reasoned.
- Pair with frontend UI implementation and design system consistency when shipping durable fixes.