Accessibility and Performance

How web performance impacts accessibility and the business.

Web performance is all about making websites fast: loading, rendering, and interacting. When pages load slowly or have a lot of content to load then the experience can be very clunky and unpleasant for all users. More resources to download mean also more data that needs to be transferred through the network and processed. Let’s explore user and business impact and how this could be improved.

Known user impacts

To be able to interact with the page browser needs first to download all necessary resources like scripts, stylesheets, images, and other data. What is noticeable is sluggish interactivity for keyboard users and the screen reader loading progress because the browser is struggling with downloading resources and at the same time constructing the page based on what is available already.

One of the most impacted areas is the keyboard and screen reader navigation. A keyboard and a screen reader are very closely linked and in general (skipping touch devices) you can’t operate a screen reader without the keyboard. Anything that impacts keyboard navigation will most likely affect a screen reader user: sluggish usability, unavailable form controls, and focus being dropped because of dynamic changes on the page.

But how and what actually is happening behind the scene?

Technical aspects

Assistive Technologies (such as screen readers, eye-tracking systems, speech input software) and browsers need to be able to talk to each other. So, browsers convert HTML markup into an internal representation called the DOM tree. Then the browser takes the DOM and modifies it into a platform-specific Accessibility API that can be understood by assistive technologies. It is a tree of accessibility objects that assistive technology can query for attributes and properties and perform actions on.

The Accessibility API tree includes four properties for each element: name, description, role, and state. Sometimes it is not possible to provide all information from the HTML itself, especially when we want to use form hints and error messages, live content updates, and more. For that purpose, WAI-ARIA markup is used that is designed specifically for communicating semantic info to assistive technologies.

W3C says:

WAI-ARIA provides Web authors with the following:

• Roles to describe the type of widget presented, such as “menu”, “treeitem”, “slider”, and “progressbar”.
• Roles to describe the structure of the Web page, such as headings, regions, and tables (grids).
• Properties to describe the state widgets are in, such as “checked” for a check box, or “haspopup” for a menu.
• Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page.
• A way to provide keyboard navigation for the Web objects and events, such as those mentioned above.

Example:

<textarea rows="5" value="" id="description" name="description" required></textarea>

Accessibility API and what’s exposed for above element:

Name: "Description (required)"
aria-labelledby: Not specified
aria-label: Not specified
From label (for= attribute): label "Description (required)"
placeholder: Not specified
aria-placeholder: Not specified
title: Not specified
Role: textbox
Invalid user entry: false
Focusable: true
Editable: plaintext
Can set value: true
Multi-line: true
Read-only: false
Required: true
Labeled by: label

You can see an Accessibility tree for example in Chromium-based browsers. Example:

How performance impacts Accessibility

The tree generated by the DOM may change a lot. When the tree changes, the browser notifies assistive technology that a section of the tree has changed or been updated. Making a JavaScript update to the DOM that triggers a reflow or repaint will almost certainly generate or rebuild an accessible object for it. State changes in ARIA do not recreate objects, but they do emit events. Many events are grouped to minimize the impact on performance (see Event Coalescing). You may notice sometimes like screen reader hangs and waits till the browser tries to gather and construct the whole page from all resources.

To reduce the work that the browser must do while constructing the DOM and keeping up-to-date Accessibility API is to avoid expensive operations where the browser has to recalculate how to position and display objects in a webpage. See also What forces layout / reflow.

Optimisations

The following approaches should help to increase the browser loading and rendering performance:

1. Use a virtual DOM and apply changes once all structures have been constructed. For example using <template> or DocumentFragment.
2. Prefer native built-in HTML elements and attributes over custom.
3. Delay loading what’s not critical, but impacts the page rendering.
4. Eliminate render-blocking resources (in Google Core Web Vitals it’s called First Contentful Paint (FCP)) – scripts, stylesheets, and HTML imports that block or delay the browser from rendering page content to the screen. Combine multiple stylesheets into one file. The same for JavaScript files and use async or defer attribute for <script> element.
5. Google Core Web Vitals have the following areas that can be measured:
   1. Largest Contentful Paint (LCP) which is the metric that allows you to measure the loading time of the largest visual element of a site.
   2. Cumulative Layout Shift (CLS) which is a metric that evaluates site experience by measuring how much your site’s pages shift unexpectedly.
   3. Total Blocking Time (TBT) which is a metric that measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses.

Conclusion

Reducing the download and render time of a site improves conversion rates, user retention, and user experience. Conversion is impacted by performance. Improving site performance load and render boosts conversion because users expect a website to load in 3 seconds or less, and often even less on mobile devices. They might start to lose interest and confidence if the site is sluggish to respond to user input or seems janky.

Making websites loading and render fast isn’t always a trivial task. It requires tradeoffs and sometimes even a whole rewrite of some part of the code.