Clarifying questions (to product/PM/UX)
- What target accessibility standard/level (WCAG 2.1 AA, 2.2 AA, ARIA practices) and timeline?
- Which user personas or assistive technologies must be prioritized (screen readers, keyboard-only, voice control, low-vision)?
- Which browsers/platforms and components/state variations are in scope?
- Any regulatory/legal requirements or analytics on current a11y issues?
- Are there existing design system tokens/components to reuse?
Accessibility checks & manual tests
- Automated: axe-core, Lighthouse, Pa11y; run in CI and locally.
- Semantic checks: correct headings, landmarks, form labels, alt text.
- Keyboard: full tab/shift-tab, focus order, skip links, focus visible styles.
- Screen reader: NVDA, VoiceOver walkthrough for component states.
- Color & contrast: WCAG contrast ratios (AA/AAA) with tools like Contrast Checker.
- Resize & zoom: 200% zoom, responsive reflow.
- Pointer/hover: ensure functionality without hover, touch targets >=44px.
- ARIA: verify only when needed; role/aria-* attributes correct and not redundant.
Iterative plan to compliance
- Define scope & acceptance criteria (checklist mapped to WCAG level).
- Implement semantic HTML and minimal ARIA; include automated tests.
- Run automated scans + fix high-severity issues.
- Manual keyboard + screen reader pass; log issues with reproducible steps.
- UX review for focus styles, contrast, and microcopy; update designs if needed.
- User testing with assistive tech (small sample) before sign-off.
- Add regression tests to CI and update docs/design tokens for reuse.
This approach ensures measurable progress toward the agreed WCAG target and integrates accessibility into development and QA.
