36 lines
1.5 KiB
Markdown
36 lines
1.5 KiB
Markdown
# ADR 0006: Accessibility Verification Plan
|
||
|
||
**Status**: ✅ Approved
|
||
**Date**: 2025-12-11
|
||
**Owner**: Delivery Lead (Accessibility)
|
||
|
||
---
|
||
|
||
## Context
|
||
|
||
Per `spec-kit/checklist.md:11`, we must validate the site against WCAG 2.1 AA. The brand guidelines emphasize accessibility, but we need a repeatable verification approach to prove compliance.
|
||
|
||
## Strategy
|
||
|
||
1. **Contrast & readability**
|
||
- Ensure text/background combinations meet at least 4.5:1 (body) and 3:1 (large text).
|
||
- Use Chrome DevTools’ “Contrast ratio” overlay on hero copy and CTA text.
|
||
2. **Keyboard navigation**
|
||
- Tab through the hero, cards, CTA button, and future forms; focus states must be visible with `outline: 2px solid #8B5CF6`.
|
||
3. **Semantic markup**
|
||
- Use proper heading hierarchy (`<h1>` for main hero, `<h3>` for cards) and descriptive button text.
|
||
4. **ARIA & assistive tech**
|
||
- Add `aria-label` or visually hidden text for any icons (future forms or CTA icons).
|
||
5. **Automated checks**
|
||
- Run Lighthouse/Playwright axe scan (when we have a full flow) and log results in `spec-kit/accessibility-log.md`.
|
||
|
||
## Evidence
|
||
|
||
- Record Lighthouse “Accessibility” score screenshots after each hero/content iteration.
|
||
- Note any WCAG failures and remediation steps in `spec-kit/accessibility-log.md`.
|
||
- Keep a short checklist for keyboard focus states (hero CTA, cards, future forms).
|
||
|
||
## Future Work
|
||
|
||
- Integrate a11y testing into CI once forms/multi-section pages exist.
|
||
- Add role/aria attributes to dynamic lists/modal states when they are built.
|