Why we should support users with no JavaScript
TweetWhy 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:
- A somewhat local newspaper site….92 JS files, 1.5 megs, onload fires 1 minute 3 seconds.
- I turn off JS when I’m going to what I believe might be a dicey site, since that the vector for most malicious software.
- Usually people don’t turn their JavaScript off, but JavaScript is filtered by company proxies for security reasons.
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:
- Start with plain, well-structured HTML to display all your content, ie all forms should submit, ensure all links can be followed.
- Next add the CSS to create an advanced layout. This essentially provides your non-Javascript version
- Javascript should be the final layer that adds enhanced behaviour to those users that have the capability. This is where you can
preventDefaulton 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
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.
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.
[…] Thoughtful post from Emma Sax […]
Hello,
I’m the first comment to the Victor Tsaran (@vick08) blurb above (the 92 JavaScript files). Here’s a screenshot of that problem for the record:
http://i.imgur.com/t0JKW.jpg
@cancel bubble thanks for the addition!
[…] Why we should support users with no Javascript […]
Nice post, very well documented and explained. Keep up the good work.
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.
@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.
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?
[…] HTML Basic Tutor – Learn to code your web pages/blogs […]
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.
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.
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.
@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.
[…] Accessibility – Why we should support users with no Javascript […]
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.
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?
Peter, that quote was a response from Martin Kliehm – I haven’t actually looked up any stats! It’s a good point.
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.
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)
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
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.
[…] Why we should support users with no Javascript – in a word, progressive enhancement (ok, that was two words, not one) […]
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.
@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.
What about if you simply could care less for users who haven’t got JavaScript?
@Alex, then it sounds like you’re doing a sloppy job. You must base support on web stats and facts.
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.
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.
@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.
@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.
@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.
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.
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
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.
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
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.
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.
[…] Punkchip points out the slight decline in percent of users with javascript disabled; from 1.6 to 1.4% between 2010 and 2012. […]
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.
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.
[…] disabled on a user’s browser. (How often is “sometimes?” Apparently, it’s somewhere around 2% of the time, at least in the United […]
Regular websites aside…
I’m developing a hybrid mobile app, and if it wasn’t for Javascript, I wouldn’t be able to come close to the performance and feel of native apps on mobile devices. If I even attempted an HTML+CSS-only hybrid app, Apple could easily deny submission into their App Store simply because the experience would be too plain and not be consistent with the experience users expect in their ecosystem.
In any case, iPhone or Android or whatever, I doubt there’s even a way for a user to disable Javascript for the entire system… this would mess up a huge amount of apps (I read somewhere that 40-50% of apps are hybrid-based).
I think could definitely still disable scripting in the full browser apps on their device, ie mobile versions of Firefox, Chrome, etc. However I would assume this has no effect on Javascript on hybrid web apps.
Anyways just thought I’d add these thoughts. For me it’s an easy choice, and I take the perspective that my product INCLUDES javascript and the user will benefit by it.
What about falling back to users who don’t support HTML? Text-only, like an email or BBS. Or would that would be releasing my content as a printed book? How far back do we go?
[…] scenarios, I want to clarify something before getting into the argument of whether we should support users with no JavaScript or not. I believe both sides of the argument have valid points; however, […]
Thanks for the article! I think the last edited date is incorrect.
InMyOpinion, excluding old (no js) is elitist.
There are a lot of indignant and ignorant comments on this post. I suggest that it is not necessary to forego a rich app experience, nor to make the entire functionality of your app work without js.
But it’s a good idea to ensure that the core capabilities of your app still work if js is broken or disabled. Very few people disable JavaScript deliberately, but there are many ways it can fail. A blank page is bad for business.
Look at Amazon, GitHub, and others. These are not simple content sites. They have lots of rich interactivity that requires js. But their core experience still works without it. You can still shop on Amazon with no js, even if not all the dynamic widgets load. You can do almost everything on GitHub without JavaScript too.
Sure, if you’re making a game or some rich graphical bi tool, you have no choice. But that’s not most (corporate) web development.
It’s entirely possible to build a functional core experience on standard, RESTful, server-rendered principles, and then enhance the hell out of it with progressive, unobtrusive JavaScript. Users with the best clients get an awesome experience, but if something guess wrong they can still do their jobs.
I’m all for using minimal JS, but keeping everything working with none at all is expecting too much. Currently, I’m working on a project that’s all about looking through a massive amount of JSON objects presented in a faster, visually appealing way. Without the JS to parse all the objects and display them as styled, marked up strings of content, there would be no purpose to the app at all. Considering the demographic for the app is mainly people who write code, I’m just sticking with a call to turn on JS using a noscript tag. I suppose I could write it all out as one massive table if I didn’t mind eating up a huge chunk of their bandwidth and melting their CPU, but I’ll pass.