Progressive enhancement is not always possible

- Posted in web - 3 comments

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.


  • Roel Van Gils says:

    I haven’t read Resilient Web Design, but I understand it’s about building and designing websites. It’s not about building apps using web technology. (For that, I recommend the excellent Apps for all by Heydon Pickering. I’ve learned a lot from this book.) is not a website; it’s an office suite that happens to runs in a browser. Nobody expects a presentation app, a word processor or a spreadsheet app to work when JavaScript or CSS are not available. That doesn’t make sense.

    I think you shouldn’t confuse transactional websites (,, etc.) and business applications (CRM type systems, administratieve back-ends etc.) with web apps that try to mimic or replace desktop apps.

  • Johan says:

    Now I’m going to go Jeremy on you but: what exactly is a web app and what is a web site? Everything is a website because it’s a page that you visit on the internet. There’s just a spectrum of interactivity between them.

    I used to think there was a very real difference and I made the same arguments as you. I actually fought Jeremy on this topic for ages. While I used to think of Pages in the browser as a “web app” and Gov.UK as a “web site” the line quickly gets blurry. What is Doodle? What is Flickr? If you go to Flickr organizr, does the site suddenly become an app because that part is more interactive?

    When I manage my data in the transactional websites (e.g. my eBay auctions) I am pretty much doing the same thing as when I’m saving data in a CRM type system. Why is one a website and the other a web app?

  • Roel Van Gils says:

    Sure, it’s hard to draw the line between when you’d call a website or a ‘web app’. Maybe that doesn’t even matter.

    People who believe that anything that can be reached by typing a url in a browser should be built in a ‘progressively enhanced’ way, are just wrong. I guess we agree on that. However, I don’t hink that’s what Jeremy Keith wants us to believe.

    It’s rather obvious why you can’t ‘progressively’ build a spreadsheet application by starting out with plain old HTML, then make it look pretty by adding a presentation layer and finally enhance the experience using JavaScript (that’s basically what progressive enhancement on the web means.)

    You can’t ‘enhance’ something that’s not even possible by the nature of HTML (such as drawing, formatting text, doing calculations in a spreadsheet). I do think that most applications that deal with entering information that’s being stored and processed on the server (and is made available again in an app-like interface) are perfectly suitable to be built with progressive enhancement in mind. Simply because the core functionalities of these apps are available in HTML already (entering information using form elements, sending it to a server to process and store, display it using lists, tables, images etc.)

Leave a Reply

Your email address will not be published. Required fields are marked *