Johan Ronsse

In december I read the excellent “The Case Against Progressive Enhancement’s Flimsy Moral Foundation” (and its followup) which poses some interesting thoughts on some of the arguments that some of PE’s biggest proponents put forward to defend their position.

I started learned webdesign in ’06 and I was heavily influenced by the web standards movement. I was basically schooled by the likes of Zeldman, Jeremy Keith, Dan Cederholm and Andy Clarke.

In my last post I praised Jeremy’s Resilient Web Design but at the same time stated:

My only critique that – as a designer of highly interactive applications – the example of progressive enhancement is way too simplistic. But I guess that’s just where I’ve never agreed with Jeremy anyway.

If you want to read said example, I refer you to the part about software in Chapter 6 of Resilient Web Design, where they talk about Editorially (RIP).

I am happy that the concept of progressive enhancement exists and I am a big proponent. But at the same time I feel the need to talk about situations where PE is less than feasible; and where it’s just nonsensical.

Since PE is sometimes presented as a “moral” argument where PE’ers have the moral high ground (“If you don’t progressively enhance you don’t care about users!”) I want to talk a bit about the practicality of said enhancement. This is also partially covered in Chapter 7 of Resilient Web Design which talks about the challenges we face towards the future.

I get that in this React-world there needs to be some education about where we are coming from. If some people think it’s OK to build a simple content website that does nothing when the Javascript doesn’t work, they need to be schooled. Obviously content websites need to be built on a solid HTML base. There needs to be a separation of concerns between structure, presentation and behavior wherever feasible.

The gist of the progressive enhancement logic is that everything can have a fallback, thus creating a web that is less likely to break and more accessible. When the Javascript fails there should still be server-side navigation. When your CSS doesn’t load you should still be able to use the website. The idea is that you layer tech on top of each other and when one piece fails you have a fallback.

The problem is that this is not really true.

Not everything is a content website consisting of pieces that can have “fallbacks”. Vast pieces of software are being built with web tech. Apple’s Pages in the browser is an entirely different beast than your average news website. Enterprises are moving every bit of their software to a web stack.

In theory most of the things in these software packages can be progressively enhanced. A data table can be turned interactive. A tree component can be made accessible, as evidenced by the WAI-ARIA examples on Github.

This is all nice and dandy until you actually try to make it work across different browsers, platforms, screen readers etc.

I guess I have a problem with hardline PE’ers who have only ever created simple content websites, and then take a “moral high ground” stance.

The higher the level of interactivity the harder it gets to create a fallback.

For images you can write an alt text. For video you can create transcriptions. But things get progressively harder and time consuming – as anyone who has ever done subtitling for a two hour conference talk can attest.

Some visual representations of data — like calendars, or scatter plot charts — make no sense to a visually impaired person. You could try to describe the data, but depending on the chart that is nigh impossible.

One fallback solution for some things is to build an alternate way to access the same data. For example, for a calendar that means a list view.

But when you reach a certain level of interactivity there’s just no way to keep the PE argument up.

For example, a lot of tools to create content itself are impossible to be “progressively enhanced”. There is no fallback for your canvas in a drawing app. How exactly do you apply PE thinking to something like Figma?

Last year I worked on a tool that is basically something like Hype in the browser. An animation tool with a timeline. How does this get a fallback? Even if you were to find an appropriate fallback for individual pieces (e.g. a progressively enhanced color picker) you wouldn’t be able to use the application anyway if one thing breaks.

If you’d spent any time trying to progressively enhance something that is that highly interactive, it basically means that you’re spending dev time for a situation that just doesn’t exist. Sometimes dev time spent on PE is just nonsensical.

The argument that it’s not possible to progressively enhance something is sometimes used too soon – but in my experience building highly interactive web apps there are plenty of situations where I can argue that no, it’s not going to happen.

A lot of my job is about making sure software doesn’t break, that we use the right (web) tech, and that we build accessible interfaces. But there are plenty of situations where I just have to tell PE hardliners that the story is just a bit more complicated than they think.

“Resilient Web Design” by @adactio is an important book. Many of the references are among the best writing I’ve read during years of learning about web design. My only critique that – as a designer of highly interactive applications – the example of PE is way too simplistic. But I guess that’s just where I’ve never agreed with Jeremy anyway.