46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# 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.
|