Mastering Accessibility Acceptance Criteria for better user stories
summary
A set of pragmatic Accessibility Acceptance Criteria (AACs) is developed with a retailer: start from 20 common failures, reduce to 10 acceptance criteria (effectively 7 applied often), and express each in BDD format like "Given I am a keyboard user ... then I can control it" so outcomes map to WCAG without drowning BAs in technical detail. Examples cover keyboard, visible focus, labels, screen reader updates and alt text; teams self‑serve more, audits show fewer low‑hanging bugs, but measurable impact remains unclear and companion docs plus training and a GitHub repo support rollout.
AI-written summary · about
chapters (14)
- 0:00Inclusive Design 24 intro
- 1:23Documenting accessibility needs
- 4:36Accessibility acceptance criteria
- 7:3210 core accessibility criteria
- 12:21Using behavior-driven development format
- 19:11Balancing simplicity and coverage
- 23:34Testing with hypothetical feature
- 27:02Method benefits and limits
- 33:43Resources and contacts
- 34:26Q&A: criteria and WCAG
- 39:45Measuring impact in orgs
- 42:19Handling missed requirements
- 43:55Integrating into roadmaps
- 45:29Closing remarks
related talks
26mHow (Not) to Fail at Accessibility
33mAccessibility needs to be the future of better technology
38mHow to set up an accessibility program in an imperfect world
38mGuidelines on Designing for Accessibility in UX Design
45mAccessibility: Why You Should Learn About WCAG
26mThe Ultimate Practical Guide to Accessibility Testing
42mArchitecting for Accessibility
45mTips from the Trenches: Accessibility Testing