JavaScript and Progressive Enhancement

It's 2022, and 36.8% of respondents (not a representative survey, but assuming the demographic of Sara Soueidan's Twitter followers to be dominantly web developers: even more shocking) don't know what Progressive Enhancement is.

This short intro by Chris Ferdinandi, cheekily titled as if it were something really new and cutting-edge, not only clears up with some myths but gives a hands-on intro on how to build good websites by progressively enhancing, rather than limiting, user experience with JavaScript. It's a really good primer to use in the apparently needed continued education for more inclusive and robust practice in creating digital artifacts.

This goes really well with yesterday's bookmark, providing some hard facts on just how common it is that users do not receive JavaScript assets assumed by the developer:

Stuart Langridge presents this simple, yet convincing flow chart to illustrates all the various things that may go wrong as users request a web site requiring JavaScript code.

As with technology use vs. non-use, working JavaScript in a browser is not a binary dichotomy (script support on vs. off), but a fluid scale with various degrees of support. A good designer and developer takes this reality into account and builds good experiences immune to such aspects.

For some evidence in form of hard numbers:

This is a 9 years old article. Yet, while the quantitative numbers may have shifted in one direction or the other, the qualitative statements stand unchanged: it cannot – and must not – be assumed that all JavaScript code is executed for every visitor of a website.

1.1% of people aren't getting JavaScript enhancements (1 in 93)

And this is not about "people deactivating JavaScript", an assumption too easily brushed away by an ableist and short-sighted "it's their own choice, most of the web will be broken without" argument. It's about a range of circumstances that permanently or momentarily may lead to users not getting the complete set of files envisioned by the developer.

So while these are interesting reasons, ultimately the reason why someone doesn’t receive the enhancements is largely irrelevant. What's important is understanding how many people this is, and now we know.

A robust and responsible website is built in a way that is resilient enough to still "work" if such unforeseen limitations occur. That's the beauty of progressive enhancement.

The same argument as in this research-based article can be found in a more visual presentation by Stuart Langridge:

As for the original research by the GDS: it would be really interesting to see current data using this same (ingenious) research methodology; the experiment was apparently re-run in 2017, but I could not find publicized results.

Terence Eden tells the story of a young woman who, forced by circumstances, has to use a public website using a tiny gaming device's browser. And it works. Because designers did their job:

The PSP’s web browser is – charitably – pathetic. It is slow, frequently runs out of memory, and can only open 3 tabs at a time. [...] But the GOV.UK pages are written in simple HTML. They are designed to be lightweight and will work even on rubbish browsers. They have to. This is for everyone.

Such a great story, and a reminder that accessibility is not about "disabled users" but about universal access for everybody:

Are you developing public services? Or a system that people might access when they’re in desperate need of help? Plain HTML works. A small bit of simple CSS will make look decent. JavaScript is probably unnecessary – but can be used to progressively enhance stuff.