Why we should support users with no JavaScript

Why should we want to support users that, for whatever reason, have Javascript disabled? I had found it difficult to answer this question in a constructive way, whilst also being backed up by research. This post aims to give you some reasons why we should still be supporting users without Javascript.

Not an accessibility issue

The 2010 WebAIM Screen Reader Survey found that only 1.6% of screenreader users have no Javascript when browsing (compared to 10.4% the previous year)so that argument is wearing thin.

The 2014 WebAIM Screen Reader Survey found that 2.4% of screenreader users have no Javascript when browsing – although this is an increase from 1.4% the previous year, the argument is still thin.

By ensuring an application can be navigated using the keyboard and by using WAI-ARIA, Javascript can be used in an extremely accessible way for all users.

Don’t continue the myth that supporting non-Javascript users is an accessibility issue.

Make the decision based on facts

A recent number crunch of the logs at Yahoo, produced a number of stats that prove non-Javascript users still exist. How many users have JavaScript disabled? The answer is an average of 1.3% (a high of 2.06% in US and a low of 0.26% in Brazil).

Last year (2013) the GDS team asked themselves the question what proportion of people are missing out on their JavaScript enhancements. The answer is an average of 1.1%.

Well-designed web sites and applications always keep in mind the people who have JavaScript disabled.
Yahoo – How many users have JavaScript disabled?

If you take The Guardian as an example, the current average visitors per day is around 2,200,000. 1.3% of that is 28,600 users browsing without Javascript. Per day.

If you have the figures available, base your decision to support (or not support) Javascript-disabled users on those rather than world averages.

Why wouldn’t Javascript be available?

@vick08 asked his followers:

I’d like to hear some reasons as to why people may want to have their javascript turned off?
@vick08 status

A handful of replies shows that some users actively decide to turn off Javascript, whilst others may not have an option to browse with it:

Other reasons can include users who have a limited data allowance and just want to view content without the extra features (and usually extra bandwidth) that Javascript provides and mobile users browsing on low-spec devices.

It’s out of your control

Gawker recently launched a redesign of all of their sites and immediately users were presented with empty pages all because the Javascript failed to load. The industry struggled to understand how such a prominent company could make the decision to have all pages rely on Javascript.

Gawker/Lifehacker have violated the principle of progressive enhancement, and they paid for it immediately with an extended outage on day one of their new site launch.
isolani – Breaking the Web with hash-bangs

Relying on Javascript is dangerous. Errors can be introduced in a couple of unexpected ways. The first is the failure of external advert code, over which you have no control and secondly is friendly-fire in the form of console.log() left in by your developers (this causes scripts to fail if Firebug, or similar, is not enabled in the browser).

How should pages be developed?

Always develop with progressive enhancement in mind, by thinking about your coding in layers:

  1. Start with plain, well-structured HTML to display all your content, ie all forms should submit, ensure all links can be followed.
  2. Next add the CSS to create an advanced layout. This essentially provides your non-Javascript version
  3. Javascript should be the final layer that adds enhanced behaviour to those users that have the capability. This is where you can preventDefault on submits and links and start to create a nicer user experience with AJAX and Javascript.

A Romanian translation of this article has been provided by Web Geek Science

43 comments on “Why we should support users with no JavaScript”

  1. I browse with noscript running all the time, if I see a site that doesn’t cope with this very well I rarely enable it unless it is a site I visit often, even then it is only the temporary enable.

  2. Agree.

    People confuse javascript with jQuery with Ajax, etc.

    There’s javascript to improve a website interface with jQuery and javascript to build RIAs or web apps, then you have APIs and web services, infographics/visualisations. All these use javascript in different ways because they are different things and shouldn’t be bundled together.

    My main issue with javascript for all is that it breaks down the progressive enhancement of a markup language, that can be taken and reused for say, converting to kindle format, css for visual presentation and rapid reskinning and javascript for interaction. For some businesses, a rich media product its the product, for others it just distracts the user from the actual content, think reading on a Kindle versus reading on an iPad, backlit devices problem aside.

    What is the difference between web pages that navigate to each other like The Guardian and a web page where you call via ajax more content like Salon? For starters, the business model of page impressions and advertising. Then issues like permalinking, clipping, which can be addressed nevertheless.

    At the moment, platforms are exploding: you have desktop sites, mobile sites, tablet sites, mobile/tablet native apps for iOS, for android, for Windows phone, browser add-ons, widgets for blogs, APIs from twitter and facebook… Each require a different, thought out approach to its javascript implementation.

    The bottom line, great for developers, terrible for companies: the Internet used to be a new marketing channel, now it’s gone multichannel and the cost of that will be that SMEs will be priced out by the big behemoths or that they will have to invest in smart developers that can create a good website that renders well in all platforms.

  3. Some good points, but I must take issue with “Don’t continue the myth that supporting non-Javascript users is an accessibility issue.” There is more to accessibility than catering for screen readers.

    I have neurological problems and have learned to keep javascript disabled because too many sites use it for slide-shows, animated advertising, etc. with no other way to turn them off. Moving images/text, especially when employed in more than one area of the screen at a time, make reading the page almost impossible for me, and others with similar conditions.

  4. @Lesley – the problems you mention are not because Javascript itself is inaccessible, it’s because the developer has not written or used it in an accessible way.

  5. I agree, Emma. I’m simply making the point that because so many developers can’t/won’t use Javascript in an accessible way, there are some users whose only defense is to disable Javascript. Surely that is another valid reason to support users without Javascript?

  6. Pingback: Anonymous
  7. I think we need to dispel the myth that accessible means screen readers. Accessibility means your site is viewable and navigable by the largest audience possible (both human and machine). So, by definition, making your site accessible with javascript disabled is an accessibility issue.

  8. There is a new accessibility issue though – which is what happens if you use the new HTML5 semantic elements with browsers that don’t support them. A: you have to use a bit of JavaScript to identify the elements in the DOM.

    Does that mean that to cater for users without JavaScript we still can’t justify using the new HTML5 elements (e.g. ). There obviously has to be a compromise somewhere and ultimately it does depend on the combination of JavaScript usage and browser usage.

  9. Hi Emma,

    Thanks for the post. I understand that screen readers have come a long way in terms of support for JavaScript. Do you happen to know if there are any uses of JavaScript that still pose a problem for the readers? It’s my understanding that the readers load the DOM into its own cache and sometimes that doesn’t get updated to reflect the changes made using JS. Just wondering if that’s still an issue.

  10. @Rob – it’s my understanding that screen readers have become more sophisticated (beyond loading the DOM into its cache) and can handle most aspects of interaction. However, I don’t know of any exact cases where Javascript might still cause a problem – if you find out please let me know.

  11. I use noscript. I enable javascript for the sites I really care about but most of the time I just figure a site that is lame without javascript isn’t worth bothering with. Doing so helps with 2 things 1) javascript can be used a vector for attacks 2) much javacript code is just useless, fluff that adds nothing and actually detracts from usability.

    I am amazed by the many lame sites I run across of sites have simple links not work without javascript and similar things. yes if I really really want the content – ok, fine put up with badly programmed sites. But most of the time it is just a signal to not waste my time with that site.

    I understand there are some very cool uses of javacript that can actually enhance my experience of the site.

  12. I am not sure if the argument “JavaScript is filtered by company proxies for security reasons” is correct. In the past couple of years I have not heard of any company filtering javascript. Do you have any stats to back that up?

  13. Peter, that quote was a response from Martin Kliehm – I haven’t actually looked up any stats! It’s a good point.

  14. Does anybody remember when Google Analytics stopped working for a couple of hours last year? Almost every site I visited in that time didn’t work because JavaScript failed to load, another reason to ensure you develop without it.

  15. Well,

    I could understand how your arguments look like when you want to say that JavaScript “could not be working” on the system.

    Come on, dude… what’s up with your C64? Are you still relying on that? Ever thought about a buzz word called “update” or similar?

    I would suggest using no JavaScript-based layouts. That makes totally sense.

    But only if all IE market share has gone. Otherwise there’s no possibility for cross-browser websites. Don’t try to argue with CSS hacks. I won’t use hacks. And I won’t use serverside generated FrontEnd-Code…that’s just unmaintainable. …and Feature Detection is impossible without JavaScript.

    You could implement a standard called HTMLReloaded 1.0 that would drop all legacy support…but then you would exclude all those stupid Windows users out there that have still IE running and no plan about anything on the web (even if it’s displayed in a red 200px font right on top of the page). Either you exclude them – or the Lynx browsers out there. It’s not a hard decision for me. I would exclude both (=D).

    Have you ever seen a blind using not IE or Firefox? Do you think there’s a browser out there that supports aria standards and interfaces for braille devices without having implemented JavaScript?

    (Fellas, The discussion here is not about buzzing again html5 or canvas.)

    Greetings,
    Christoph (WebApps WG)

  16. Well, I just wanted to clarify my statement.

    I’m definitely not into those HashBang-hypes or having JavaScript as a depency on a working layout. A well-structured HTML file won’t require JavaScript for the layout that has definitely to do with CSS.

    But if you are developing WebApps, especially games or Sites that won’t use Flash (which is probably the badest solution)… you’ve got to detect the css support for it… having a css animation with transitions or a JavaScript fallback.

    Why is it that way? Because otherwise there’s no API on the browser side to detect it. It’s the only way to have a site running in 2 years after Browser XY in Version Z came out without having to update the serverside files. Server-side detection makes no sense at all, because you then have to face multiple problems with capability layers, “user agent sniffing” and bunches of other bullshit I may not have seen yet.

    But it’s no solution to sniff Agents and rely on them… what about faked UA strings from Proxies? Ever thought about them? =)

    So, JavaScript is the only way to have A) anything dynamic and B) anything evented. There’s no other language that can face these two things. Seriously.

    Greets again,
    Christoph

  17. I think the out of control point is not very accurate. It’s only out of your control if you are running 3rd party scripts. A console.log, with any level of testing, is no more harmful than a bug on the server-side.

    In general, I HIGHLY encourage people to build applications without progressive enhancement. It’s much easier and there are fewer people with JS disabled than using IE6.

    If you are building something that needs to be indexed by Google, then build your app with progressive enhancement in mind.

  18. Just 1 issue that hasn’t been brought up here. Cost! It costs time (money) to adjust your JS in a way that is accessible to all users and browsers. It also generally makes the code heavier.

    So you really need to decide whether you’re going to become a volunteer developer or a professional one. If you’ve decided on professional, then you need to weigh the cost of losing non-js enabled users vs the cost of coding for them.

    As far as catering for people with real disabilities, get real mate. Anyone who has the kind of condition that’s going to be affected by js is just as likely to be affected by an animated GIF, and shouldn’t be using a PC at all.

  19. @John, although I can understand your point about development time/costs, I would argue that being a professional web developer IS about making your pages as accessible as possible (and yes, that should apply to apps too).

    I am afraid that your comment stating that:

    “Anyone who has the kind of condition that’s going to be affected by js is just as likely to be affected by an animated GIF, and shouldn’t be using a PC at all”

    is exceptionally arrogant and offensive. I can only assume that, as a fellow professional, you had a bad day, mate. That statement looks like one step away from just sending all the ‘cripples’ on a nice wee train journey – a practice that’s been kind of frowned upon in the civilized world.

  20. I get it and I agree mostly. However the Gawker example is a poor one. I went to log into my bank the other day and part of their site was broken because of a Java error. The Gawker example is sort of like saying – don’t use Java because a single error will crash your whole site. Duh. Would things have been better if Gawker had created JavaScriptless layout? absolutely. However, one can also argue that putting buggy code into production is probably the thing to avoid.

    It doesn’t invalidate your point, it’s just not a good example.

  21. I am a web developer and currently am working on a site where to do a non javascript version would double the cost. My client has said I should forget the small percentage of people who don’t have javascript enabled because the extra cost of a non javascript version makes the project financially impossible.

    It’s all very well for sites with millions of visitors to cater for non javascript users but I think it’s unfair to label sites as badly programmed when they all have to be made to a specific budget reflected by a specific quota of visitors.

    If your site just displays information it’s much more feasible to think about a non javascript design. For sites with many features it simply isn’t realistic.

  22. @Jason, if your stats say you don’t have a need to cater for non-js users then obviously that is a decision to be made from project to project.

    It’s bad practice when you ignore non-js users just because you can’t be bothered.

  23. @Emma, (just this first bit)..I agree entirely. Not sure why you directed your comment at me.

    Since reading this post and the comments, I decided to try and find some of these people who either have no javascript or have disabled it. Probably half the people I asked have no idea what javascript is. The ones who do know or have a vague idea what it is have never disabled it and no-one I have asked has a computer and browser set up old enough to have no javascript by default. I would therefore question how many people in fact have javascript disabled. I have probably asked in the region of 100 people and not a single one has javascript disabled or has any reason to have it disabled. Can anyone verify the statistics given? They seem unrealistically high to me. I would hazard a guess that it is more like 1 in every 1000 people on average.

    I haven’t even included mobile phone users where I would guess the amount of non-computer literate users is even higher and therefore an even lower percentage of those would be able to or would want to disable javascript.

  24. @Jason the stats were take from Yahoo! and WebAim – a study on web traffic and a survey on users respectively. These are very reputable sources.

  25. HTML5 and its APIs use javascript intensively. So I dont think supporting no-js users is important. Theyr number will decrease a lot this year. Plus “users” that don’t enable js on theyr browsers may be spiders, mostly.

  26. I am quite confused about these whole comments. I am new to web design and all this argument about using js or not makes me feel uncomfortable. i have asked myself this question about non javascript users. 80% of web sites built today makes use of js for functionality.but with hacks for non compatible browsers (IE)it would have been a nightmare.As at now i find it difficult to take a decision whether to use js for web browser hacks and if the user have js turned on

  27. Well, as many of the others, I use NoScript. When I see a site which doesn’t work, guess what I do. Okay. I always use Unix-based operating systems, such as Linux, and I always have a dumb account with empty home directory which is used just to launch the browser. So here I go:

    ssh -X dummy@localhost firefox &

    and here it comes, the instance of the browser which is running under unprivileged account. Even then, my machine is still under some danger, but only in the sence of denial-of-service.

    JavaScript is dangerous and malicious BY DESIGN. Hell, just one thing which people always tend to ignore: simply the time of rendering for the page. If there’s no turing-complete code to run, it is a (almost linear) function of the html length. But if there’s a turing-complete interpreter, be it JS or Flash or whatever, not only the rendering time is no longer a function of anything, but it even CAN NOT BE PREDICTED! Because it is now an unsolvable problem (I mean, mathematically proven to be unsolvable).

    Imagine a small statue on a shelf in your room, which is there for decades, and one day it starts to tick just like a watch mechanics, leaving you with no idea what it will do next – may be it will say you “happy new year”, may be it will explode when you sleep. This is what the very concept of JS looks like.

    The users who disable damn javascript are the most intelligent internet surfers, who understand something about the computer security. And they HAVE THE RIGHT to do so.

  28. I agree websites need to be accessible without Javascript. However I don’t recommend having plain HTML forms anymore. Any plain HTML form I deployed in this decade very rapidly became a spam vector for automated comment spam.
    I render forms in Javascript, takes away 90% of spam submission

  29. Welcome to websites that look like 1999.

    Uninformed people disable Javascript thinking they are more secure, or immune from ads, they are not.

    Turning Javascript off makes your browser no more secure than having it on.

    You’d need to turn off all plugins, CSS (yes it’s vulnerable) and somehow disable all javascript debuggers that can manipulate your browser completely even with Javascript turned OFF.

    Ignorance is bliss.

  30. Blackberry curve default browser has no JavaScript. We can not rely on it for the mobile experience completely. Best practise is progressive enhancement. If you rely on it for a feature or entire app make sure that fits the use case and target audience but if a standard website better I believe to not rely on it completely.

  31. I am working on a large complex site all alone. I started out trying to do only progressive enhancement, but my design for how I want the site to look and interact required a decent but not large amount of javascript for UI interaction. It got to the point where I had to call it quits and just design my site the way I want it and not care about the 2%. It got to the point I realized that if I were to progressively enhance and create a matching full page for every Ajax feature I had I would never in 1,000,000 years complete the site, especially if I were trying to go with the full supporting of all browsers for CSS and all flavors of HTML/XHTML and on and on.

    I decided that I’ll keep my ajax to a minimum but where I have to use it for the interface interaction then I do and eventually I can HIRE PEOPLE to add all the other code for no JS users and users with old browsers and blah blah blah. All that crap sounds good and comes from people that work at large CORPORATIONS that have huge sums of money to hire tons of people to spend all of the time to create all of that extra code.

    Also you should minimize all js and CSS code and put a cache on it. Then your user downloads the file only one time and it stays in their cache until the clean it out or it expires. Also you can use Googles CDN for jQuery and other libraries. This saves you bandwidth plus users who have been to other sites that use the CDN already have jQuery downloaded

    But yeah, I tried the whole progressive enhancement thing and it is something only corporations can afford to do in the end as a small business or single developer you can’t really worry so much about the 2%. If what you create is good and it makes money then you can hire people to add that later, plus by that time the site will need upgrades and many changes and features so it would be better to do it then as part of a redesign than to worry up front and never get a product to market.

  32. Apps that work without javascript are much harder to write but as someone already wrote they give back, is a long term investment. The biggest issues are with link building and state holding that are related. It is much easier to build them with javascript as orchestrator and state holder instead than propagate state through requests.

    However if links are created with javascript they cannot be deducted by a spider and for example, leaving aside the usual google argument, you cannot test with a spider whether an app is 404-free, there is less semantics involved.

    Also, we cannot know whether a next generation of devices (micro?, super safe?, just new ?) will support javascript, it’s years people say no-script is finished, it just not happened yet.

Add your comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>