Thoughts on web performance and web accessibility

Note: This post is older than two years. It may still be totally valid, but things change and technology moves fast. Code based posts may be especially prone to changes...

(Loaded 645 times)

Attended web performance conference (performance.now()) and found some thoughts about similarities with accessibility. Also made a simple proof of concept for a time to interactive metrics for screen-readers and other assistive technologies.

I learned only some basics about web performance when learned for the – now retired – Google Mobile Web Specialist certification.It was mostly about image optimization, deferring and async loading JavaScript, critical CSS and lazy loading images below the fold and other best practices. That was before Googles Core Web Vitals (CWV) became a thing.

After online sessions with my accessibility mentor, Léonie Watson she invited me to meet her in person and attend a conference she really liked and where she presented a lecture about performance and accessibility – performance.now() – opens in new window. I don’t usually go to conferences if they have online options, but this time I decided to go there to meet her in person and to also learn more about web performance from world’s experts. Both things were amazing and as a bonus I also meet Hidde de Vries (opens in new window), another accessibility expert that stopped by.

This post will be about some thoughts that crossed my mind while attending the conference.

Performance and accessibility share quite a lot of similarities

When seeing some slides I almost wanted to shout – “hey, it’s just like accessibility”. Getting all the team members and stakeholders on-board, so that they know enough to have a performant website, team efforts – that really reminded me about accessibility.

Personally I do think that accessibility is more important than performance. Because if things are not accessible, then performance doesn’t really come into play. But the problems in the terms of organizations are similar. Awareness, knowledge, preventing regressions.

The difference again is in the measurements. We have way better tools to measure performance and they also evolve way faster compared with accessibility testing tools. It’s probably quite obvious – as we can’t really test accessibility automatically. But also performance in some aspects can’t really be tested automatically. So again a similarity.

Then again – it’s crucial to set so called performance budgets that make the sites performant and also make sure their performance issues don’t re-appear. The same could be said for WCAG – it can also be like an accessibility budget, although it will be way more inflexible compared to performance budget. We know that WCAG has levels, so maybe we could say that our accessibility budget is conformance to WCAG on levels A and AA but also including some AAA success criteria.

Performance does have direct impact on accessibility

As Léonie lectured in her Accessibility: the land that time to interactive forgot (opens in new window) – performance of the website has direct impact on the performance for assistive technology.

It’s logical – to be able to use a screen-reader, for example – the operating system needs to finish the normal browser cycle and only then the accessibility tree can be produced that serves as a interface to screen-reader. So if original flow has poor performance then the overall performance will only be worse.

Another problem that has impact on both performance and accessibility is the complexity of the site – all those nodes – even the non-semantic ones like divs and spans. Complexity of HTML, CSS and JavaScript all add to performance and stability issues and with that also performance and stability for accessibility.

Core web vitals should include time to the accessibility tree creation

In the slides from Léonie I’ve seen an interesting GitHub request for metrics that are inclusive to assistive technology (opens in new window). It is a request to add the metrics to Lighthouse that would indicate times when assistive technologies like screen-readers can interact with page content. Basically when the accessibility tree is generated and can be operable.

The discussion evolves about differences in platforms and browsers, but they kind of agree that it would be a good start to get it into Chrome at least. Paul Irish mentioned good points about Time to A11y Tree First Build metric (opens in new window) and it really made sense to me. The thread seems to be stale from April of 2021, and last comment was a ping from Léonie.

I did some research and found about Accessibility.loadComplete event

After hearing about it from Léonie and checking the GitHub issue mentioned I decided to quickly check if something is already possible via Puppeteer. I’ve done aXeSiA based on Puppeteer, so I had some basic knowledge about it and remembered it has an option for accessibility tree and an option to use the Chrome DevTools Protocol (CDP) to get more info.

I stumbled upon CDP’s Accessibility.loadComplete event (opens in new window) and it really seemed like the perfect thing to make the metrics based on.

So I used some free time while waiting for the delayed airplane to take me home from the conference and made a simple proof of concept where I used the Accessibility.loadComplete event (opens in new window) to get some metrics from it. As mentioned in the documentation – it’s probably very wrong – but I think it could be a good start to just get the Time to Accessibility Tree First Build metrics or something like that.

Hope Lighthouse will be getting something more reliable in the near future. It would only add to awareness for accessibility and I think could make more people dedicated to it as well.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: