Accessibility and Performance

By Marcy Sutton / @MarcySutton
Senior Front-End Engineer, Deque Systems

Who is Marcy Sutton?

axe-core Web Accessibility Slack
Girl Develop It

CNN VoiceOver demo


Browser developer-tools waterfall indicating back end versus front end
Steve Souders: The Performance Golden Rule


The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability.

Who are we talking about?

  • Limited Mobility
  • Blind, Low Vision
  • Color Blind
  • Cognitive/Learning
  • Deaf, Hard of Hearing

Accessibility and Performance?

  1. Accessible interfaces
  2. Quicker operability
  3. Fewer steps to task completion

“You can’t optimize
what you can’t measure.”

Navigation Timing API

“Letting a website know you’re using a screen reader means running around the web waving a red flag that shouts “here, I’m visually impaired!”… It would take away the one place where blind people can be relatively undetected without our white cane or guide dog…and therefore giving others a chance to treat us like true equals.”

Marco Zehe: Why Screen Reader Detection is a Bad Thing

A11y + Performance:

What do we have?

  • Known user impact
  • Optimizations
  • Universal apps
Page 1 of The Keystroke-Level Model for User Performance Time with Interactive Systems Research Paper
Conspiracy Keanu: What if Performance is actually about limits on human memory

User Impact:

Interacting with the keyboard

  • Are you waiting for JS to load?
  • Is the UI thread blocked?
  • Does the UI depend on JS for everything?

“I keep spending 20 seconds staring at a page that has not yet executed the bulk of its code”

The parts of Twitter that do not work without JavaScript highlighted in red

User Impact:

Assistive Technology

  • Are you waiting for JS to build the DOM?
  • What is the loading experience like?
  • Is the Accessibility Tree slow to update?

What is the Accessibility Tree?

Objects impacted by HTML, CSS and JavaScript

Chrome Accessibility Tree of HTML5 video element

Chrome Accessibility Inspector

Chrome Accessibility Inspector looking at a form input
Gecko rendering flow
Mozilla's Gecko rendering engine main flow

HTML5 Rocks: How Browsers Work

Gecko rendering flow with Accessibility Tree
Mozilla's Gecko rendering engine main flow (updated)

HTML5 Rocks: How Browsers Work

Things that impact the Accessibility Tree:

Changes in JavaScript that impact layout/reflow

  • display: none;
  • elem.computedRole
  • elem.scrollTop, other scrolly things
  • window.getComputedStyle()

...and much more. Use sparingly while loading.



Use as many browser defaults as possible

  • Buttons & links
  • HTML5 inputs
  • Focus styles

Everything you customize has to be sent over the wire.


Include keyboard support
in the critical rendering path

Critical Rendering Path diagram

Prioritize accessible interactions.

Full-screen GIF and no login modal

Universal Rendering

a.k.a. "isomorphic JavaScript"

Load the same app from both the server and client

Isomorphic JavaScript steps




Don’t: Hide Content on Load

React blog loading with hidden body React blog loaded
iOS Safari with no Accessibility Information beyond page load React Universal Blog demo in iOS Safari
React Universal Blog demo in iOS Safari before hydration React Universal Blog demo in iOS Safari after hydration

Do: Use progressive enhancement

Airbnb homepage without JavaScript Airbnb Seattle search page without JavaScript

Do: Utilize event playback

Preboot by Jeff Whelpley


  • Think beyond visual performance
  • Optimize for accessible actions
  • Simplify your interfaces
  • Use technology to help more users