The intersection of accessibility and performance
summary
An accessibility audit of a medical-education single‑page app finds Material Design radios that force a large DOM (6 elements, 9 attributes, depth 3; 66 CSS selectors/141 properties → 10 KB; 2,374 lines JS → 30 KB) and cause VoiceOver to crash. Replacing them with a tested 3‑element pattern cuts HTML by 50%, DOM depth by 33%, CSS selectors/properties by 30% and CSS payload by 90%, removes 30 KB JS, and VoiceOver stops crashing. Notes performance wins from accessibility tree sampled from the DOM and Firefox yielding 10–20% faster accessibility calls.
AI-written summary · about
chapters (17)
- 0:00A problem with accessibility
- 1:13What is the accessibility tree
- 2:08Building accessible components
- 3:00Example of a dialog component
- 4:22DOM vs accessibility tree
- 6:21Fragility and technical limits
- 7:48Improving performance with HTML
- 10:32Tools for auditing
- 11:11Case study: optimization
- 12:50Tangible benefits of optimization
- 14:16Process boundaries and speed
- 16:06Taking action and tools
- 17:34The impact of slow machines
- 19:23Civil rights and responsibilities
- 21:08Cognitive load and design
- 22:59The necessity of user testing
- 24:38Conclusion and resources
related talks
51mAccessible is Performant
30mAdvanced HTML for Performance & Accessibility
17mDesigning A11y with Material Design
46mMobile accessibility - challenges and best practices
39mElegant Accessibility
33mMarkup matters
49mAccessibility and Performance
59mAccessibility for UX: Don't worry, it's much worse than you think