Accessibility: The Sprint Filler Way
summary
Accessibility is framed as a bug to fix, not a feature to add later, and fixing it early—start with a team definition of done and reusable components—reduces repeated work. Concrete tools and numbers: use Lighthouse and axe-core/axe plugins for audits, add eslint-plugin-jsx-a11y plus a Husky pre-push hook to lint before pushes, and integrate axe into tests. Conservative stats: ~15% of people have disabilities and only ~10% of sites are accessible, implying a possible 15–30% uplift in engagement/revenue.
AI-written summary · about
chapters (8)
- 0:00Introduction and speaker intro
- 1:24What is disability
- 5:18What is accessibility
- 8:58When to add accessibility
- 12:34Business case for accessibility
- 16:58Tools for accessibility
- 21:13Automating accessibility checks
- 22:00Closing remarks
related talks
14mAccessible Accessibility
45mTips from the Trenches: Accessibility Testing
29mHow to bring accessibility into your teams
26mAccessibility Is a Marathon, not a Sprint
22mPrioritising Accessibility to Web Development
29mBuilding Accessibility Testing into Your Workflow
12mAccessibility-First Development: Making Applications Inclusive from Day One
34mBuilding Accessible Careers