Accessibility at all stages
summary
Argues that embedding accessibility from analysis through testing saves time and money: a major bank delays launch after a late audit finds an inaccessible drag‑and‑drop mortgage flow and a keyboard‑untestable slider, forcing redesign; audits a week before launch often expose 50 issues at launch instead of a few. Recommends concrete practices: focus groups including people with disabilities, design reviews to flag complex interactions, inclusive usability testing with screen readers and keyboard users, fallback patterns like input text alternative for custom controls like sliders, reusable accessible component libraries and named accessibility champions.
AI-written summary · about
chapters (13)
- 0:00Start
- 3:35Inclusive design
- 10:30Late accessibility - bad examples
- 15:13Causes problems for the organization
- 16:03Causes problems for your employees
- 17:47Software development life cycle: When SHOULD accessibility be considered?
- 20:21Business analysts
- 22:46Project managers
- 23:44Designers
- 25:08Developers
- 38:41Summary
- 39:48Questions
- 41:10Consider accessibility first!
related talks
54mLean accessibility: Building inclusive design into your agile workflow
08m"Accessibility! Why should I care?"
57mHow (and why) to 'shift-left' your accessibility testing
33mEmbedding Accessibility
12mAccessibility-First Development: Making Applications Inclusive from Day One
19mAccessibility isn't hard; getting people to see it's easy can be with Sarrah Vesselov
28mBuilding in accessibility for broader value to all
26mAccessibility Is a Marathon, not a Sprint