There's more to performance than meets the eye

A11yClub, Berlin November 2018

Léonie Watson

Transcripts

https://decks.tink.uk/2018/a11yclub/transcripts.html

Web performance

The speed at which web pages are downloaded and displayed in the user's browser

Browsers


Chrome	Edge	Firefox	Safari
(Google)	(Microsoft)	(Mozilla)	(Apple)

Screen readers


Jaws	NVDA	Voiceover	Narrator	Orca
(Freedom Scientific)	(NV Access)	(Apple)	(Microsoft)	(GNOME)

Screen reader demo: text

Screen reader demo: language

In the late 90s

Screen readers consumed the HTML directly from the browser, and created a virtual model of the content

Screen reader demo: headings

Screen reader demo: buttons

In the early 00s

Screen readers began using accessibility APIs to query information from the browser

Accessibility APIs


UI Automation (UIA) MS Active Accessibility (MSAA) IAccessible2 (IA2)	OSX Accessibility Protocol (AXAPI)	Accessibility Toolkit (ATK) AT Service Provider Interface (AT-SPI)

The `details` & `summary` elements

<details>
<summary>Tequila...</summary>
Makes me happy!
</details>

Edge: not implemented

Firefox: implemented

The accessibility tree: `summary` element

Role: button
State: focusable; focused; expandable; collapsed

Screen reader demo: `details` & `summary` elements

In the late 10s

All screen readers use accessibility APIs to query information from the browser, but not all create a virtual model of the content

Single process model

Single browser process that managed the application, content, and other common tasks

Multi-process model

Separate application process, one or more content processes, and processes for handling other common tasks

Communication architectures

In-process communication: Screen reader injects itself into the application process, and communicates directly with the browser

Out-of-process communication: Screen reader communicates with the browser across application boundaries

Multi-process: IE

Screen reader injects into the application process, and has direct access to the content process

IE: approach

Accessibility API calls made directly into the content process

IE: accessibility performance

Fast Time To Interaction (TTI) and subsequent performance, but prone to instability

Multi-process: Chrome & firefox

Screen reader injects into the application process, but does not have direct access to the content process

Chrome: initial approach

Proxied accessibility API calls from the application process into the content process

Chrome: current approach

Caches a copy of the accessibility tree in the application process

Chrome: accessibility performance

Possible slow TTI, but fast subsequent performance

Chrome: screen reader TTI

Firefox: approach

Proxies accessibility API calls from the application process into the content process, but uses intelligent caching

Firefox: accessibility performance

Good TTI and subsequent performance, but accessibility performance issues introduced with Quantum remain unresolved with some screen readers

Multi-process: Edge

Screen readers cannot inject into the application process, and do not have access to the content process

Edge: approach

No caching, all accessibility API requests are handled via the OS

Edge: Out of process communication

Out-of-process calls are 12 to 50 times slower than in-process calls, making a performant virtual model impossible

Edge: accessibility performance

Fast TTI and subsequent performance, but limited capability

Edge: Narrator

Narrator is integrated into the OS, and does not use a virtual model, so is reasonably performant

Safari: VoiceOver

VoiceOver is also integrated into the OS, and does not use a virtual model, so is reasonably performant

Performance: drop the virtual model?

Screen readers depend on the virtual model to improve human performance

Screen reader demo: selecting content

Screen reader demo: select using placeholders

Performance: improve accessibility APIs

Accessibility APIs need the same features that screen readers have in the virtual model

Screen reader demo: searching with UIA

Performance: code well

Things that hit general performance will have an impact on accessibility performance

Thank you

To the following people, for answering many questions:

Jamie Teh, Marco Zehe (Mozilla)
Glen Gordon (Freedom Scientific)
Alice Boxhall, Rob Dodson, Dominic Mazzoni, David Sexton (Google)
David Storey (Microsoft)
James Craig (Apple)
Michael Curran (NVDA)

Screen reader demo: Because human performance

Thank you!

A11yClub, Berlin November 2018

Léonie Watson