Should we provide our user's with an experience when they do not have JavaScript enabled? At face value a relatively simple question, yet one that fuels debates across the entire Web Industry.

With the subject matter creating such a strong division between the sides of for and against, all discussions ultimately degrade into chaos and becomes a game of who can shout the loudest.

Recently, Josh Korr published an opinionated blog post on the reasons against progressive enhancement, especially surrounding JavaScript's place in the workflow.

On the back of a twitter thread sparking outcry from the Industry, I noticed a conversation between Rach Smith and Sara Soueidan reacting to Josh's blog post.

After reading through their thread and a reactionary blog post from Aaron Gustafson, I completely understand where Rach is coming from, many people still don't fully understand the arguments for and against Progressive Enhancement and instead of reasonably looking at each side's views we become pubescent teens unable to have a thoughtful discussion on the matter.

With that said, for the rest of this blog post I'm going to play devil's advocate, a neutral party looking to provide insight into the points that many make for and against a non-JavaScript experience or just Progressive Enhancement in general.

Let's begin.

"Websites should be accessible to all users"

Accessibility will always be a hot topic, and the Web Industry is no exception. When we think of Web Accessibility though, what are we actually referring to? Well, if we're taking the classic definition of accessibility then the W3C's Web Accessibility Initiative describes Web Accessibility as...

Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.

Web Accessibility Initiative, 2005

Someone unfamiliar with the concept of Web Accessibility may then believe the book stops there, to provide an accessible website for people with Physical or Mental disabilities. If thats you then I'd like to reference a WebAIM survey from 2012 that disproves the idea that JavaScript is inaccessible for people with disabilities by showing that 98.6% of screen reader users have JavaScript enabled, with the numbers being even higher for people with low visionary impairments.

However, I, like many others describe Web Accessibility as a much broader subject and being the inclusion of all users, no matter their:

  • Physical or Mental capabilities;
  • Device and browser used;
  • Connection speed or quality;
  • and any other unknown factors about them.

Based on this definition, you can start to understand why people are so protective over the subject, is it not our duty to cater for as many people as possible?

Telling someone they cannot use your website because they don't have JavaScript enabled could be likened to telling someone in a wheelchair they cannot access their bank because there are too many stairs. Just as we might complain at said bank for not including a ramp, they may feel the same way about a website not providing an experience outside of JavaScript. Granted that experience may not be identical, but 'something' is always better than 'nothing'.

Moral obligation is a great motivator, however, who draws the line? Perhaps the Government? Are we legally obligated to provide an experience for users without JavaScript? Whilst I'm no expert in UK law, after a little research into the UK Equality Act 2010, it only mentions the more traditional approach to accessibility by stating that...

A person (a “service-provider”) concerned with the provision of a service to the public or a section of the public (for payment or not) must not discriminate against a person requiring the service by not providing the person with the service.

Section 29: UK Equality Act 2010

With there being seemly no legal obligation to cater for user's without JavaScript (in the UK at least), the book then ends with the project team. Do they want to support an experience outside of JavaScript? If so are we now talking about a battle between Moral Obligation vs Financial costs? For the Moral Obligation, allow me to provide a counter argument.

"Our application requires JavaScript"

Whilst most website's will force themselves into using JavaScript as a preference, there are some website's that simply don't have a choice, which is where things get tricky. When a product requires JavaScript as its primary language for functionality, how do we then provide an experience for user's without? Google maps is a prime example of this.

Google Maps does not provide support for user's without JavaScript

Fig 1: Google Maps does not provide support for user's without JavaScript

As seen in the image above, Google Maps does not support an experience without JavaScript being enabled. Many interactive website's out there require JavaScript to run, as there is not an alternative experience that can be presented with just HTML and CSS. In this case, should the developers be held responsible for not providing an experience to those user's without JavaScript? Of course not, there is no possible experience they can give other than "This website only runs with JavaScript enabled".

That being said, a lot of people misconstrue this notion to justify their development stack.

"Our Framework doesn't work without JavaScript"

With the rise of frameworks such as React and Angular in the past few years, many believe that JavaScript can no longer be purely an enhancement to the initial HTML & CSS layers and has grown into being the website itself. In their eyes, without JavaScript you don't have a website, just like we might say the same about HTML.

Personally, I believe this to be a fallacy and an inherent flaw with the current JavaScript frameworks we have to hand. No matter the language, frameworks never are nor will they ever be a requirement for a project. A framework by definition is a structured approach to development in a particular language and fundamentally uses the same code as any vanilla counterpart. True, a framework may provide you with some development benefits such as scalability and maintainability of a project but they are by no means a requirement.

Therefore, by using a framework which pigeon-holes you into this mentality, you're putting the ease-of-use for you as a developer over the needs of your potential user's who cannot use JavaScript (for whatever reason). Whether that's right or wrong is for you as a team to decide, but don't use the excuse that your preferred development stack does not support an experience outside of JavaScript as a justification.

On the flip side, what are the benefits of Progressively enhancing a website with JavaScript? Let's start with the obvious financial benefits first.

"You'll reach more users with Progressive Enhancement"

The more users that you allow to access your website, then the more business you will create as a result. We all know this by now, the primary goal of any website is to have as many people viewing it as possible, so to enable people without JavaScript to experience your website is always going to be a financial gain, right? I thought so too, but looking at the data may prove the opposite.

How many people use your website without JavaScript enabled? Unfortunately, just looking into your Google Analytics isn't a reliable solution, as the UK's Government Digital Service (GDS) found in 2013 when they discovered that only 0.2% of people had JavaScript disabled in their browser or don't support it. However, upon further investigation they also uncovered that a further 0.9% of people didn't receive JavaScript even though they had it enabled on their browser, possibly due to one of the following reasons:

  • corporate or local blocking or stripping of JavaScript elements
  • existing JavaScript errors in the browser (ie from browser add-ons, toolbars etc)
  • page being left between requesting the base image and the script/noscript image
  • browsers that pre-load pages they incorrectly predict you will visit
  • network errors, especially on mobile devices

Number of gov.uk users without JavaScript

Fig 2: Number of gov.uk users without JavaScript.

That's 1.1% of the entire user base for the gov.uk website, which caters for user's of varying backgrounds and origins, handling typically around 10k users every 5 minutes. Whilst every website will have different levels of traffic, I'd go out on a limb to say gov.uk has one of the highest requirements for Accessibility in the web and provides a solid baseline for us to work from.

Now, if we're focusing at purely the financial concerns, one could argue whether 1.1% of traffic is actually worth supporting.

Side stepping a little into Browser Compatibility, we might take a browser only being used by 1.1% of traffic as unworthy of the development work needed to cater for this browser, yet we're supposed to do the exact opposite for user's without JavaScript? Why?

In an ideal world with unlimited budgets I'd definitely invest the time to optimise a website for all users, however, we don't live in an ideal world. For businesses with tight budgets, I can definitely see why they would say no. Quite honestly, the time would be better spent in other areas of the business, depending on what the ramifications are for Progressively enhancing the user's experience when we know they have JavaScript capabilities.

It all depends on the costs

If you're telling me its going to take a few hours to create support then I'm sure there wouldn't be a problem, however, if we're taking a couple of weeks then that might be a different story. Assuming your hourly rate is £50 per hour and you work 8 hours a day, 5 days a week then £150 is far different to £4000.

The main thing to remember here is the decision should be on a case by case basis, rather than a blanket yes or no. The next time you come onto a project, ask yourself:

  • What is the budget for this project?
  • What are the time scales we're working towards?
  • Can I actually provide an experience outside of JavaScript?
  • What are the costs to do so?

Concluding thoughts

Hopefully by reading this post you've realising that creating a website which provides an experience without JavaScript and the topic of Progressive Enhancement in general is not as black and white as one may think. There are arguments for and against so each project needs to take these points into consideration before coming to a conclusion.

In addition, I'd like to think the next time we see opinionated posts such as Josh's, we approach them with less pitch forks and instead try to weigh up both sides of the coin to come to mutual agreements. Let's work together, we're better than this.

Further reading

Until next time 👏


# Related posts

Like what you've seen? Want more? Check out similar posts on Assortment that you may find interesting:


# Comments

  1. #1 Posted:

    Aaron Gustafson

    I generally agree with everything you have written here with the exception of your characterization of my post as "reactionary". My post was a reaction, yes, but it was much more evenhandedly presented than that word implies (at least in American English). In fact, I made many of the same points you’re making here.

    I did want to take a moment to clarify a few things:

    1. The GDS’ 1.1% of users having no JS support is a number specific to them. Your sites may vary. Depending on how you collect your analytics though, your stats may also be wrong. If you are using the default Google Analytics setup, for instance, JS is required to collect analytics data and nothing will be recorded in a no-JS scenario. It’s important to keep that in mind.

    2. Your percentage of no-JS users should be viewed in terms of real numbers. Using the GDS number, that’s about 1 in 93 people. It may not be a big deal if you get 100 visitors a day, but if you get 1 million, that’s 110,000 people who effectively get nothing if you have not provided a fallback.

    3. When you switched from the 1.1% being applied to no-JS users to browsers, you said "In an ideal world with unlimited budgets I'd definitely invest the time to optimise a website for all users". I’d make the case that this is one of the problems of perspective we run into frequently on the Web. Folks think we need to provide the same optimized experience across the board, when we can be much more pragmatic than that. Brad Frost characterizes it as "support vs. optimization" and I think that’s a good line to draw. We can provide a very basic experience to older browsers and it becomes easier to do that when we have a no-JS experience to fall back on ("support"). We are then free to focus on building a first-rate experience for modern browsers and key browser/device combos ("optimization"). For instance, if you’re not on IE9 or better, none of my sites will give you JavaScript or any sort of advanced CSS; that makes it so I don’t have to test those browsers as thoroughly and ensures users still get something (a very "no frills" mobile-first experience). I’m free to focus on the modern browsers and have the security of a fallback if a device or browser comes in that’s not on my radar. It’s a lot like Yahoo’s Graded Browser Support, if you’re familiar with that.

    As I mentioned in my post, your choice to support a no-JS experience will depend greatly on the kind of project you’re building. I’m not adamant that everything work without JS, but I do see benefits for building that way and I sincerely believe more sites could benefit from going that route.

    Reply to this comment
    1. #1-1 Posted:

      Luke Whitehouse

      Hey Aaron,

      By the sounds of it I've not explained myself on a few things very well which is where you've picked up on. To note:

      Referring to your post as "reactionary"

      As you say, I was just trying to refer to the fact that the idea of the post came from Josh's article, although I get that the article went on more about the broader topic much like this post. Probably not the best way of describing things.

      no-js statistics using real numbers

      Agreed, perhaps introducing some numbers much like I did with the timing aspect would solidify the notion that 1.1% can still be huge, just as the gov.uk deals with. I can imagine this being something that people with less experience on the subject may trip up on so thanks for clarifying.

      Thanks for taking the time to give this a read Aaron, appreciate it and glad to know we're on the same page!

# Leave a comment

No wookies will get this, its just for your Gravatar image.

Basic markdown supported, go to FAQ for more info.