Monday, June 9th, 2008

Require Javascript for Contributions?

Category: Accessibility, Editorial, Usability

<p>

On the Stack Overflow blog, Jeff Attwood asks Is it OK to require JavaScript to participate?

Note that by “participate” I mean “edit, answer or ask a question”. Of course passively reading a question and the associated answers will work fine without JavaScript enabled.

While we do believe in progressive enhancement, it’s possible that some of the features we’re building for asking and editing may be so dynamic that they do not degrade well, if at all.

What say you? Is it OK for a website in 2008 to require JavaScript for active (not passive) participation?

On a forum site like StackOverflow, is it an “enhancement” when you add a comment? Not really, which would make me lean towards keeping the site simple and not requiring Javascript for making basic contributions. There is also accessibility to consider (although “accessible” is not the same thing as “Javascript not required”).

It could be argued that as a developer-focused website, Javascript can be assumed. But developers are also the most likely folks to go out of their way and turn Javascript off. And developers are also among the most critical of sites that require Javascript (or Flash) when it could have worked without it.

Related Content:

Posted by Michael Mahemoff at 3:53 pm
21 Comments

+++--
3.3 rating from 22 votes

21 Comments »

Comments feed TrackBack URI

Since there are still big companies (and some server-pools in universities) with script-removing firewalls, so you’ll exclude possible clients from the business and education sectors. Depends on the your target, if you take that risk. Developers also created the Firefox Extension No-Script to disable all JS (to make FF “really safer” against the evil JS monster) and only allow it on trusted sites. Which brings another responsibility, gain the users trust so he disables some of his possibly script-blocking browser-settings. That is why I usually implement my JavaScript/MooTools with Mahemoff/Heilmann/Keith’s progressive enhancement rules in mind.

Comment by Harald — June 9, 2008

I disagree wholeheartedly. We’re at a point where javascript usage is ubiquitous and someone that has it turned off knows that their choice limits what they can experience on the internet. I’m not going to design my sites to degrade for people who knowingly disable a useful feature in their browser just like I won’t for someone who chooses to use Lynx.

I’ve never seen such a Luddite resurgence as I have with JS.

Comment by AjaxianReader — June 9, 2008

I agree with Harald above. Strict firewalls, certain antivirus-program features, some companies have extremely picky proxy server etc.

I think, at the end of the day, that very few people turn off JavaScript deliberately. However, I’m sure that many people have it completely or partly disabled due to circumstances they can’t control.

Therefore demanding JavaScript for relatively simple features such as partaking in a discussion, would probably be perceived as respectless by the end user if it’s not up to them to control it.

Comment by robnyman — June 9, 2008

+1 for agree. With both server- and client-side programming frameworks as developed as they are today, it’s trivial to accomplish progress enhancement. The lowest common denominator of a website should always be full functionality. Javascript should never be relied on to deliver a functional tool, it should just be used to deliver that functionality with a more pleasant user experience.

Comment by starkraving — June 9, 2008

Progressive enhancement all the way. As starkraving says, it’s not even that hard, especially if this is for things like his markdown live preview–just augment a textarea.

Comment by bander — June 9, 2008

Actually, sites that are progressively enhanced are seemingly better constructed and easier to maintain. In the instance of using MVC + Zend, your bootstrapper can choose to return the content as JSON when there is an XMLHttpRequest.

Problem solved!

Comment by Liquidrums — June 9, 2008

I think requiring Javascript for advanced functionality where that functionality is your selling point is pretty reasonable. It’s just important to remember that the only people who will be using your product are people who can and choose to leave Javascript enabled, and use a browser you choose to maintain compatibility with. (Duh.)

Comment by eyelidlessness — June 10, 2008

I may be wrong here, but going for progressive enhancement should improve your web spiders reachability, and make your application easily bookmarkable.

Comment by icoloma — June 10, 2008

Not necessarily. Typically, though, you are right.

Comment by ibolmo — June 10, 2008

This is one of the major accessibility concern, to have a website as functionnal if javascript is unabled.

Many browsers doesn’t support javascript, or have a different support of javascript as you may think :
- screen readers (JAWS, Home page reader, Windows-eyes, emacspeak, SpeakThis, HAL, …);
- Lynx, a free text-only web browser for blind users with refreshable Braille displays;
- Links, a free text-only web browser for visual users with low bandwidth (still alive !).

Most of these browsers are keybord-way browsed, then javascript action handle can’t be the same, when javascript is supported.

Comment by benoitd — June 10, 2008

@starkraving: the more advanced web apps are impossible to build without javascript. How do you do drag-and-drop without scripting? You can’t degrade gracefully if it’s simply not possible to deliver a feature in basic html/css.

I do agree that for a forum site it’s quite difficult to argue that javascript is required to implement that functionality, but I wish people would get over themselves and stop bashing javascript because it simply doesn’t have that bad of a track record that it deserves the punishment.

Comment by Joeri — June 10, 2008

Maybe it’s just me but I don’t see progressive enhancement as a conscious decision any more. It’s relatively simple to design systems the work by traditionally ‘clunky’ means which you can hook into and override with AJAX, especially if you’re already using one of the many excellent JS libraries now available… It’s got so I couldn’t live without jQuery

Comment by Jamie — June 10, 2008

Seems absolutely fine to me. In this day and age, Javascript plays a very important part in pretty much any web application. Even the old players like PHPBB have started to turn towards javascript and ajax or at least have 3rd party hacks that many webmasters use for this purpose. I just don’t think you can get away from JS. The point where all sites use enhanced interfaces won’t be far off and people will just have to get used to it.

Going with icoloma’s point about progressive development and search bots, surely it would be best to start developing enhanced search spiders that have inbuild javascript interpretors and can find their way around ajax pages. Or perhaps its time to go back to good old meta tags?

Comment by Ravenscroftj — June 10, 2008

This is something to address on a case-by-case basis. My general gut rule is no, you should not bother with non-javascript degradation until you have a compelling business reason. There is significant cost in terms of testing and development toward maintaining what can often become two separate applications. Many people may not remember the bad old days of the 4x DHTML browser wars, but it was actually cheaper and faster to build two separate applications – one for IE and one for Navigator. Obviously the NN style DHTML died – (’cause it sucked and ) the cost of maintenance was too great. Same story here.

You don’t try to make make your full web app degrade to WAP in the same code pages. Don’t try to make your whizzy dynamic web app degrade to vanilla web. Build two UIs if you find a good business reason (i.e. large enough customer base to offset the dev/maintenance cost) to support it.

Comment by goosemanjack — June 10, 2008

Anything you do that prevents users from using the site will obviously eliminate those users. But does it matter? If the site can be read by anyone thats going to be the biggest use case. And it would be especially important if you want search engines to index your content (which you do). As for everything else, I doubt its worth the time. In an ideal world, would it degrade? Of course. But it’s probably not worth the trade off. Maybe in version 2.

Comment by genericallyloud — June 10, 2008

I haven’t looked at the site, but I wonder how much restructuring would it take to make it degrade well? The best architected webs apps I’ve seen (this includes large scale enterprise level apps) are always built upon a core markup layer with extended behavioral layers. A lot of times progressive enhancement is a mark of good planning and structuring and actually requires less overall work to create and maintain.

Comment by WillPeavy — June 10, 2008

@Joeri: I”m doing it right now. I’m working on a website builder. I wrote all the backend coding assuming zero javascript using administrative links that actually go to a real function, and forms that actually submit. I then used PE to add behaviours to the page that submitted to those same functions but in a visual way instead. It’s still possible to build out a page using a form though, that form would have x and y, and height and width fields as raw numeric values that the rich interface replaces with draggables and resizables.

It’s not done yet, so please don’t hammer my dev server, but take a look if you want:
http://www.sitegidget.com

I’m certainly not stupid enough to suggest that I’m an expert, and would definitely welcome any feedback or code suggestions. But having gone through this process I’m now more convinced than ever that about the only thing that you’d need javascript for exclusively would be if you were designing say a video game or something.

Comment by starkraving — June 11, 2008

@starkraving: I see what you did there. Entering coordinates by hand to me is not the same feature because the user experience differs so drastically, but I’ll grant you the point. Regardless, I’m just not sold on graceful degradation for web apps on the individual page level. I think the approach of having distinct front-ends on a shared back-end (not a page-level back-end, but a code-level backend) is one that scales better.

Comment by Joeri — June 11, 2008

@starkraving: With javascript, you can create the equivalent of client-server programming. Without it, you are relegated to an extremely dumb terminal. Are we really going to debate whether or not the sets of functionality are equivalent? That’s ridiculous. Can you accomplish the same data entry? Yes. Can you provide the same experience? No. Do they have the same set of potential architectures? No.

The fact is that the majority of javascript and even ajax programming is still very much surface level and can degrade gracefully, but that is certainly not always the case. Those that are pushing beyond surface potential will tell you that there are cases that do not degrade well without basically building a separate client application. That doesn’t mean it has to be a total rewrite – I hope that there’s still plenty of reusable business logic, but it can represent a very significant development cost. Gmail degrades gracefully, but you have to click to go to an html only version. I’m sure that alternate version represents a fairly significant effort. The question is not whether or not you can create an alternative degraded app, the question is whether or not that app would be worth the effort.

Comment by genericallyloud — June 11, 2008

If implementing a technology will deny access to any customer access it should be optional. You can’t assume the whole world can run Javascript. If there is a way to do something in HTML, it should be done in HTML first. Then you can add Javascript that enables some advance UI. You should rely on good design patterns before turning to Javascript for every problem.

@genericallyloud – Why would you want to make Javascript preform the equivilant of a server side programming? I search Google just fine, and it doesn’t feel like a terminal screen. You’re overreaching when you say that you can’t provide the same experience. I use the simple HTML Gmail all the time. It has an almost identical experience as the Javascript-rich Gmail.

Comment by mattk — June 12, 2008

Leave a comment

You must be logged in to post a comment.