Accessibility: The Land Time to Interactive Forgot
summary
Browsers build a parallel accessibility tree alongside the DOM and that extra work can delay Time To Interactive — an extreme page example has 354 headings and 6095 links, which makes the accessibility tree huge. Chrome copies the entire tree and keeps it cached in application process so after an initial hit the screen‑reader experience is fast; Firefox proxies with intelligent bundling and is moving to caching; Safari’s out‑of‑process model performs well with VoiceOver. Windows screen readers still use a virtual buffer for navigation.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:41Web performance
- 4:09Accessibility tree
- 4:35Semantics
- 5:52The element
- 6:19The aria-pressed attribute
- 8:13Platform accessibility API
- 9:34Multi-process model
- 10:16In process communication
- 10:36Out of process communication
- 10:56Internet Explorer
- 12:14Chrome and Firefox
- 12:43Chrome: initial approach
- 13:16Chrome: current approach
- 16:09Safari
- 17:35Accessibility rendering path
- 18:59Heading navigation
- 21:40Objective measurements
- 22:43O Practical steps
related talks
34mAccessibility: the land that time to interactive forgot
12mHarnessing the Accessibility Tree
43mBeyond the DOM: what’s in the accessibility tree for you?
51mAccessible is Performant
27mThere's more to Performance than meets the Eye
49mAccessibility and Performance
26mThe intersection of accessibility and performance
41mTales of Accessibility Failures