Testing Strategy

<!-- CANONICAL SOURCE: .github/skills/testing-strategy/SKILL.md -- Edit the canonical source; sync to Gemini via scripts/check-gemini-sync.ps1 -->

Testing Strategy Skill

Decision frameworks for accessibility testing — when to use automated tools vs. manual testing, which screen reader + browser combinations to test, and how to write accessibility acceptance criteria.

---

Automated vs. Manual Testing Coverage

Browser + Screen Reader Compatibility Matrix

Primary Test Combinations (Required)

Secondary (Nice to Have)

Testing Decision Tree

Is it a new component or page?
├── Yes → Full test coverage (automated + manual)
│   ├── Run axe-core / Lighthouse scan
│   ├── Keyboard-only navigation test
│   ├── Screen reader announcement test (NVDA + VoiceOver minimum)
│   └── Visual check at 200% zoom
└── No → What changed?
    ├── Colors/styling → Contrast check + visual review
    ├── Interactive behavior → Keyboard + screen reader test
    ├── Content/text → Screen reader announcement check
    ├── Layout/order → Reading order + focus order test
    └── Dependencies updated → Regression scan (axe-core)

Regression Testing Patterns

CI Pipeline Accessibility Gates

1. axe-core scan: Run on every PR. Fail on new critical/serious violations. 2. Baseline management: Store known issues in .a11y-baseline.json. Only fail on new issues. 3. Lighthouse score threshold: Set minimum accessibility score (e.g., 90). Fail on regression. 4. Visual regression: Capture screenshots at 200% zoom. Compare for focus indicator and layout changes.

Preventing Regressions

• Add accessibility assertions to existing component tests (see testing-accessibility.instructions.md)
• Include keyboard navigation in E2E test suites
• Track accessibility score trends over time (not just pass/fail)

Acceptance Criteria Template

For User Stories

Given [context],
When [action by keyboard/mouse/screen reader],
Then [accessible outcome]:

- [ ] Component has an accessible name (via label, aria-label, or aria-labelledby)
- [ ] Component has the correct ARIA role
- [ ] Component is reachable and operable by keyboard (Tab, Enter, Space, Escape, Arrows as appropriate)
- [ ] Focus is visible when the component receives focus
- [ ] State changes are announced to screen readers (aria-expanded, aria-selected, aria-checked, etc.)
- [ ] Error messages are associated with their inputs (aria-describedby or aria-errormessage)
- [ ] Content is readable at 200% zoom without horizontal scrolling
- [ ] Color is not the only means of conveying information

Common Testing Tools

Screen Reader Testing Quick Reference

NVDA (Windows)

VoiceOver (macOS)