We all want that webpage we’ve been searching for to be viewable, usable, and interactive with lightning speed. But alas, that is not always the case. We have all had to "Let the Spinning Wheel spin," much to our displeasure and frustration.
Preventing, or at least lessening that displeasure and frustration are why web programmers and developers rely on web performance metrics.
"Web performance refers to how quickly site content loads and renders in a web browser, and how well it responds to user interaction. At its worst, bad performance causes content to be completely inaccessible. A good goal for web performance is for users to not notice performance."
"So when talking about performance, it's important to be precise and to refer to performance in terms of objective criteria that can be quantitatively measured. These criteria are known as metrics." ~ Mozilla
There are approximately 6 metrics that are considered the most important metrics to measure. Two of those, First Contentful Paint and Largest Contentful Paint, are said to be measurements of "meaningful moments in the visual page loading experience when content is visible (though still not yet interactive) and can be digested by users…" ~ We need more inclusive web performance metrics, Scott Jehl
But those "moments" are not meaningful if you are low vision or blind and use a screen reader. Screen reader users normally are not even aware of the steps in the page loading process. In addition, the page may not be usable by assistive devices until it becomes fully interactive. This "slow to become interactive" issue affects keyboard-only users as well.
"A keyboard and a screen reader are very closely linked: generally you can't operate a screen reader without a keyboard (I will leave touch devices out of this conversation for now). Therefore, any of the things that impact a dedicated keyboard user will most likely affect a screen reader user, as well: sluggish usability, delayed input, focus being dropped as the page is upgraded with JavaScript." ~ Accessibility and Performance, Marcy Sutton
So, what can we do to more effectively measure webpage performance for accessibility? Scott Jehl suggests that we be more inclusive in our metrics. For example, measuring the exact time when "assistive technology is able to interact with and communicate page content." Looking at the list of those 6 metrics and determining which ones do have an effect on accessibility, "for example, if a particular metric occurs before the accessibility tree is exposed." And "Lastly, how are metrics like First Input Delay translating to the interaction time that someone experiences when using assistive technology?"
Marcy Sutton suggests best practices for front-end developers to optimize performance for accessibility:
- Use the browser default HTML elements and CSS wherever possible.
- Prioritize accessible actions in the critical rendering path.
The idea of being inclusive goes beyond company culture and having a diverse design team, which are both extremely important. Measuring website performance for accessibility ensures that the webpage you’ve been searching for is viewable, usable, and interactive for everyone !
Resources
- We need more inclusive web performance metrics - Scott Jehl
- User-centric performance metrics - web.dev, Philip Walton
- The "why" of web performance - Mozilla
- Accessibility and Performance - Mary Sutton
- Request for metrics that are inclusive to Assistive Technology #11049 - Github, GoogleChrome/lighthouse