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.
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).
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.
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.