ConFoo, Montreal 2018
LĂ©onie Watson ~ The Paciello Group (TPG)
The speed at which web pages are downloaded and displayed in the user's browser
Chrome | Edge | Firefox | Safari |
(Google) | (Microsoft) | (Mozilla) | (Apple) |
Jaws | NVDA | Voiceover | Narrator | Orca |
(Freedom Scientific) | (NV Access) | (Apple) | (Microsoft) | (GNOME) |
Screen readers consumed the HTML directly from the browser, and created a virtual model of the content
Screen readers began using accessibility APIs to query information from the browser
details
& summary
elements<details>
<summary>Tequila...</summary>
Makes me happy!
</details>
details
elementdetails
& summary
elementsAll screen readers use accessibility APIs to query infomation from the browser, but not all create a virtual model of the content
Single browser process that managed the application, content, and other common tasks
Separate application process, one or more content processes, and processes for handling other common tasks
Screen reader injects into the application process, and has direct access to the content process
Accessibility API calls made directly into the content process
Fast Time To Interaction (TTI) and subsequent performance, but prone to instability
Screen reader injects into the application process, but does not have direct access to the content process
Proxied accessibility API calls from the application process into the content process
Caches a copy of the accessibility tree in the application process
Possible slow TTI, but fast subsequent performance
Proxies accessibility API calls from the application process into the content process, but uses intelligent caching
Good TTI and subsequent performance, but accessibility performance issues introduced with Quantum remain unresolved
Screen readers cannot inject into the application process, and do not have access to the content process
No caching, all accessibility API requests are handled via the OS
Fast TTI, but possible slow subsequent performance
Out-of-process calls are 12 to 50 times slower than in-process calls, making a performant virtual model impossible
Narrator is integrated into the OS, and does not use a virtual model, so is more performant
VoiceOver is also integrated into the OS, and does not use a virtual model, so is performant
Screen readers depend on the virtual model to improve human performance
Accessibility APIs need the same features that screen readers have in the virtual model
Things that hit general performance will have an impact on accessibility performance
To the following people, for answering many questions: