This one has dogged me for quite some time, but I finally figured out how to force users to turn on Javascript when using sites with a lot of mission critical Javascript logic.
Let me first begin by acknowledging that, yes, requiring Javascript flies in the face of site accessibility. Policy wonks for this sort of thing will tell you that Javascript should never be a necessity, that a page should “degrade gracefully” when Javascript isn’t enabled. This mindset is complete crap, in my opinion. Every site has a minimum browser requirement, and Javascript is built into every modern browser. I fail to see why we are still separating the two, and can make a darn good case for expecting Javascript on the user’s end. But that argument’s for another day. If you agree with me, read on.
The example
This example assumes you understand HTML, CSS, and Javascript, and makes use of jQuery, so you may have to adapt it to fit your Javascript framework of choice.
This technique could be applied across the board to an entire site, but let’s start with a single page. A login or account registration is a great choice, since they are already gateway pages to your site. Start by adding the following CSS definition to your page or stylesheet:
.enable-javascript{
display:none
}
Next, open the HTML for your page and add the enable-javascript CSS class to the top level container containing the body of your page. You should try to leave the header and footer (and their accompanying navigation links) visible and accessible. For example, after my header DIV, the body of my pages are typically wrapped in something like this:
[...]
At this point, you’re looking at a blank page. Now let’s give our non-JS users something to look at. Place a <noscript> code block outside and above the body that you just hid. You can use CSS and elaborate HTML inside a <noscript> block, so feel free to make it look good. I actually duplicate my body wrap HTML so the look is similar:
Finally, make sure the jQuery library is loaded, and add this bit of code to the Javascript for your page:
$(function(){
$('.enable-javascript').show();
});
What’s happening
We’re using the absence of Javascript to halt the user’s access to a page. By default, page content is hidden via CSS, and we use Javascript to reveal it. If the user’s browser does not have Javascript enabled, the reveal never happens. Visibility for the <noscript> block is handled automatically by the browser, depending on whether Javascript is running or not.
A live example
I’m using this technique on the Fwd:Vault login page. In order to see it in action, you obviously have to disable Javascript. You can use the Google support link to turn Javascript on, and Firefox users can use the Web Developer toolbar add-on to do this a little more efficiently.
A couple caveats
Javascript is a client-side language; it actually lives inside the user’s browser, and runs from the user’s machine. Javascript code essentially tells the browser to manipulate the static HTML of the page, and the server isn’t involved in the process at all (AJAX is something of an exception). This means that there is absolutely no way for us to look for Javascript on the server side using PHP or other server-side technologies.
In addition, since Javascript control is firmly in the hands of the user, you cannot trust Javascript for security. Your average user will be stopped dead with this technique, but hackers and code monkeys can easily circumvent it. This is the case with all Javascript effects, and all have the same countermeasure: scrub all incoming data regardless of Javascript rules enforcement.
Feel free to post comments or questions, and please link your own examples if you put this technique to use!
Guh. Please don’t use the noscript tag…
See
http://stackoverflow.com/questions/993387/noscript-tag-javascript-disabled-warning-and-google-penalty/993461#993461
for a tiny bit of code that will help you cope w/out it
and see
http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/
for some situations where the noscript tag falls flat on its face.
Well done, you reference a blog post from December 4, 2006, you win the internets
The use of NOSCRIPT should also be avoided as it appears not to work with Chrome – http://stackoverflow.com/questions/2787177/noscript-stuff-noscript-doesnt-work-on-google-chrome
Having just spent a year redoing a site we considered the effect of users coming with no JS and decided that as long as the key functions, in this case login, search, add items to basket and proceed through checkout worked then all was well.
Now now, play nice boys.
I do like the idea of substituting
<noscript>with a CSS/JS combo, gonna look into this one further.Here’s a modified version (using jQuery) of the example from Simon’s link. First the page content…
...
Welcome... here's some content...
...
and then in the stylesheet…
body.js-enabled #noscript { display: none; }Some people disable javascript on their browser because it poses certain security risks, not because they’re running web browsers from the valve-age. See http://en.wikipedia.org/wiki/JavaScript#Security for some examples of issues with JS.
So your message in the “real-world” example comes across (to me at least) as patronising. Telling them they “probably just need to turn it on” will be obvious to the security conscious crowd and probably just rile them up. Given that the service is for “secure backup”, it’s odd to exclude this security-minded target crowd. From what I could see, there was little-to-no-need for javascript at all – it was a sign in page. There was nothing there that CRUCIALLY required javascript. There’s nothing there that helps the users either – checking that they’ve entered a valid email address for example.
Overall, I find these tactics to prevent users from accessing a website based on some prejudice against the technology being used, quite frustrating. There’s a time and a place of course – if you need javascript because it’s a web-app for example. But to say it’s a requirement when it’s not – that’s frustrating.
Thanks for the feedback, Dan! Great thoughts in there. I got a little long-winded in considering a response, and apologize in advance.
You’re absolutely right that there’s nothing on the login page specifically that requires Javascript. I don’t even do the email syntax check! However, Javascript is required in order to use many of the pages a user encounters once they log in. For example, our online uploader uses AJAX to show upload progress and complete multiple uploads from a single page load. So I’m using the requirement on the login page as a compatibility check, to ensure Javascript is on and available before serving up pages that necessitate it. (Aside: for what it’s worth, I would definitely classify Fwd:Vault as a web app, which you considered permissible.)
I also totally get where you’re coming from with security concerns, being one of those people myself. NoScript for Firefox is a great plugin for the security conscious. But you don’t have to live in the “no JS” world for long to realize that you miss out on a lot of features and functions from a multitude of sites. At some point I took a step back and thought, “My security concern is impeding my ability to get stuff done on the web.” Javascript is pervasive today, and usage will only increase as technologies and standards progress. I really put it on the same level as CSS, it’s a cornerstone to solid web development.
You also have to consider exactly how Javascript poses a threat. Any attack starts the same way: they have to get you to visit a URL. To borrow a phrase, “Javascript doesn’t kill people, malicious sites do.” I’ve found that security efforts spent examining Javascript are far better used evaluating the source and only visiting reputable sites.
I also consider the practical application of script blocking to the general public. I’ve done a lot of technical support over the years and found that it’s far more worthwhile to teach a user how to spot a shady site than it is to explain Javascript and how to turn it on/off. Take your most non-technical friend or family member and imagine explaining this to them. I’ve done it, and god willing I’ll never do it again.
This is also precisely the reason I am not worried about “excluding” security-conscious, tech-savvy users like you and I. We know what we’re doing. If a user knows understands how Javascript works, typically they know how to turn it back on too. Personally I’m all for whitelisting Javascript, running it only on trustworthy sites that require it to function properly. This approach does not exclude security aficionados, it just assumes they know what they’re doing.
Case and point: you knew enough to inspect the login page and see what was going on; I’d encourage you to take it a step further and create an account, log in, and see what else I have going on. Then, when you’re satisfied, enable Javascript and start using the service the way it was intended, in all its Javascript-powered glory.