How to make your application accessible (and keep it that way!)
summary
GitHub scales accessibility by measuring and owning outcomes: running axe scans across ~100 public domains and 2,000 pages to track violations, cutting many down to near zero; mapping every file to a team via a service catalog so ownership and on‑call routing exist; training ~60 accessibility champions and hiring consultants plus a blind program lead; adding scorecards and annual ACR/VPAP audits; and converting UI tests to keyboard-only system tests that catch real bugs (one revealed a missed mouse‑only spinner load). Cost is mid single‑digit millions per year.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 3:32Why accessibility matters
- 9:31Scaling accessibility at GitHub
- 14:52Measuring accessibility
- 21:14Service catalogs for ownership
- 27:17Lived experience and audits
- 33:17Keyboard-only testing
- 35:22Cost of accessibility work
- 36:03Q&A
related talks
33mHow to make your application accessible (and keep it that way!)
42mMeasuring Ourselves GitHub’s Accessibility Scorecard
45mAccessible by default
42mAccessible by default
28mEnterprise Grade Accessibility for Everyone
49mScaling Accessibility An Accessibility Design Manager’s Tale
45mAccessibility feedback loop: Continuous a11y improvement in your development life cycle
11mOpen Source Accessibility