Progressive Enhancement Is Important Because Mistakes Happen

The discussions around progressive enhancement and failing JavaScript often center around the user or the network, but sometimes JavaScript fails to load because of the development process. While it may be a rarer occurrence, when it does happen it can be a much more severe issue. This is yet another reason why building websites with solid HTML and CSS practices first—with layered, enhancing JS second—is important.

Here's an example.

Background

I've recently been helping a colleague transition from marketing to development. She's taking over the maintenance of a small product site as a way to learn the fundamentals of web development as well as various development tools like Git and build pipelines.

The static site is built with Eleventy so it's very easy to run locally. We've also moved it from Firebase to Netlify which means a different production environment. Since build pipelines are supposed to smooth the differences between development and production environments and since the site looked good locally, the changes were merged and pushed to production.

This is where I failed by not suggesting a proper production check or more thorough testing using Netlify's branch builds. I'm definitely not laying blame on the new developer.

The Problem

A few days later the developer realised many parts of the site were broken. Among various pieces of interactivity there was the

• FAQ accordions
• navigation dropdown menu
• image gallery and video showing off the product

After a bit of digging we realised the JavaScript file lived in the /Scripts folder while the code referenced /scripts (no capitalisation). Her local Windows environment was being case insensitive while Netlify was not.

Our entire main.js file was 404-ing and not loading in production. Unlike other cases where JS doesn't load, this wasn't an intermittent issue, but a constant one!

The Solution

While the immediate solution was a simple¹ case-change hotfix, we're now working through making changes to the site to make it work without JavaScript.

The dropdown navigation can be done with CSS alone (or adjusted to remove the dropdown, making access easier). The gallery and video can be shown by default, with a carousel and modal added by JS. Finally, the FAQ accordion can be done with semantic HTML using <summary> and <details>.

Sometimes I feel like I'm shouting "Progressive enhancement is important! Accessibility is important!" into the void, fighting against the "Everyone has JavaScript" sentiment, especially in an environment where we have fiber broadband and high-end computers. It was useful to have an actual failure (thankfully low impact) to drive the point home and create a good learning opportunity.