The short answer to “when do I need a non-JavaScript solution”? Always. The long answer? Keep on reading…

When I test a new feature built by another developer in my team, one of the first things I do is to turn off JavaScript and see what happens.

Developers often act surprised at this, and look at me disdainfully for inevitably breaking their application when I choose to access it in this way. “This is a client-side calculator! Of course it’s going to break without JavaScript!”

Similarly, when I sit in on meetings with developers and stakeholders discussing what they are hoping to build, “fallback images” and non-JavaScript solutions are often treated as a bit of an afterthought. When I put forward the question of fallbacks, it doesn’t surprise me when the answer is a smirk and a “well, I suppose we’d better give IE8 something“.

We’ve all become so used to modern browsers and increasingly powerful mobile devices that the concept of a non-JavaScript solution seems an unnecessary extra effort; an additional burden on designer and developer alike. After all, the actual proportion of users who access the website without JavaScript enabled is never more than a couple of percent.

However, ignoring fallbacks due to the low percentage of users most affected is short-sighted and is missing the point.

We’re all non-JavaScript users

You may have looked at the proportion of users who access your website with JavaScript turned off through no fault of their own (e.g. corporate users of IE8) or deliberately (self-aware tech-savvies who are sick of being tracked with cookies) or who don’t even have JavaScript available in the first place (anyone using increasingly popular proxy browsers for reduced data consumption). The combined total of these users might be a tiny proportion of your overall users. Heck, it might even be zero.

This is no excuse for ignoring your non-JavaScript implementation. Why? To paraphrase somebody on Twitter:

“Every user is a non-JavaScript user until the JavaScript loads.”

We’re not all on fiberoptic broadband connections. If you’re on a mobile phone on the train and you’re about to enter a tunnel, you’ll be stuck with whatever content arrives in the few kilobytes you managed to download before the signal cut out. Which would you rather see: a sea of whitespace and badly formatted text accompanied by nothing but the prospect of a seven-minute data vacuum, or the core article text with some basic but sufficient styling?

Varying degrees of non-JavaScript solutions

Non-interactive features (such as datapics) have no interactive element and thus should get the core content, untainted by “Turn your JavaScript on!” messages. The content of the feature should be accessible and readable without jumping through hoops. Perhaps it’s not possible for the content to look quite as polished as the JavaScript version (though if we’re disciplined about using CSS for presentation and JavaScript only for interaction, this should not be the case).

Some features, such as quizzes, require client-side interaction to be of any real benefit to the reader. Is a non-JavaScript solution necessary, or even viable?

When it comes to content where advanced functionality is the core content, I still expect a few things for non-JavaScript browsers:

• Though I’m not expecting anything particularly exciting or useful, I would expect the page to not look broken.
• I’d expect a message something to the effect of “You must turn on JavaScript in order to view this content.”
• And I wouldn’t expect lots of unnecessary markup containing questions I can’t answer and buttons I can’t click.

To paraphrase another anonymous tweet:

Use JavaScript to inject the markup your interactive application requires.

So, the answer to “when do I need a non-JavaScript solution?” is… always.

Other benefits of providing a non-JavaScript solution

A better experience for corporate users of IE8 and for mobile users in temporary data blackspots aren’t the only advantages of implementing a defaults-first solution. Reasonable core-content experiences provide benefits in a number of other situations:

• Reasonable experience if another script on the page breaks your JavaScript.
  • Bugs can and do creep into live pages. Maybe the ID of the element your script hooks into has been changed, or another script on the page is re-defining jQuery at runtime, or you’ve accidentally deleted a JavaScript dependency from the server. Instead of the page spewing a load of JSON or unused markup to the user, the user will be presented with a simpler version of the same content.
• Accessibility for screen readers
  • Canvas-based interactives are not usable by screen readers. If they get a description of the fish game that they could be playing in a more modern browser, disabled users at least get an understanding of what content is on the page.
• Search engine optimisation
  • Canvas-based interactives are not crawlable by search-engine spiders. However, a simple description of the canvas content will give search engines an idea of what content exists on the page.
• Support for harsh browser environments and future compatibility
  • Who knows what lies ahead technologically? We may one day browse the web on our toasters, pub urinals, coffee cups and Boris Bikes. We have no way of knowing what level of sophistication such browsers would support. By providing core content to all, we’re future-proofing our content as much as possible.
• Clearer separation of concerns – content, presentation, interaction
  • It’s well known that HTML is for content, CSS is for presentation and JavaScript is for interaction. Keeping the three areas separate is good architecture, and supports a defaults-first development style. By delivering our non-JavaScript solution through our markup and CSS alone, we’re fitting into this programming ideal.
  • Clearer separation of concerns means more maintainable code, meaning fewer bugs, bugs which are fixed more easily, the improved ability to work in parallel with other developers (e.g. one on presentation, one on interaction), and so on.
  • Cohesive codebases and fewer bugs means hitting deadlines, and if you’re lucky, bonuses and pay rises. As developers, we’ll have gained a stronger handle on the advantages of keeping each area separate (the Single Responsibility Principle), and will strive for similar ideals in the rest of our codebase, leading to better use of object orientation and the like.
• Last but not least, making websites accessible is the law. Don’t risk being sued for having an inaccessible website. Part and parcel of this is ensuring that every solution has a non-JavaScript default.

Continue reading: Coding defaults, not fallbacks (coming soon)