Ecommerce solutions fail their customers

We have recently discovered that the majority of ecommerce software solutions exclude users who have Javascript disabled. That is like turning away 1 in 20 customers.

At Headscape we recently tendered for a piece of work that required an ecommerce solution.

After looking at the various technologies available we settled on Business Catalyst. It fulfilled almost all of our client’s requirements and because it was owned by Adobe we were confident in its long term health.

Chris Scott our Managing Director was running through his presentation the day before the pitch when quite by accident he discovered something – Business Catalyst did not work with Javascript disabled.

Business Catalyst website

This put us in a very awkward position. It didn’t even occur to us that such a powerful product would fail on such a fundamental level. Approximately 5% of users have Javascript disabled and there was no way you would turn 1 in 20 people away from a bricks and mortar business, so why would you online.

We felt morally obliged to tell our prospective client and unsurprisingly we lost the job.

We decided to contact Business Catalyst to find out their position on the subject. Below is the email we received:

Hi Chris Scott,

I am sorry that you lost the deal with this prospect based on this requirement. To be honest, this has not come up much at all in our travels!


“According to 95%-95% of browsers have javascript enabled. My experience of actual users on actual e-commerce sites is more like 99%.

Experience and research has shown that one page checkout reduces cart abandonment by upwards of 20%.
We think that losing 1% to gain 20% was a reasonable compromise.”

Even Magento, one of the more pervasive shopping cart technologies on the market has JS switched on.

And if you go to Amazon, many of the links/drop-downs do not work if you do not have javascript turned on.

So every site used on Magento, Ubercart, BC, and most other shopping cart solutions; and Amazon and probably 90% of other high profile shopping cart portals, do not meet your clients standards. Possibly they are being too pedantic. Of course, it is their prerogative to hold this viewpoint, and as such they must seek a solution that does look after these 0.5-1% of users.

As for BC, it will always require a browser to have JS turned on to work well, and in fact will only become more heavily weighted in that direction as we enhance the ecommerce solution.

I am sorry that in this instance we could not offer an alternate path/solution.


Erin Murray
The Business Catalyst Team.

Setting aside that their entire response seems to be based on an employee from a competitors forum, there is a fundamental failure in the logic.

The argument put forward by Andy in the forum is that by enhancing their checkout process with Javascript you gain more sales than you lose. However, there is no reason you cannot enhance a site with Javascript and still offer a perfectly acceptable ecommerce experience for those who do not have it enabled. That is the wonder of progressive enhancement. Now, I can forgive a random forum guy for not knowing about progressive enhancement. However, I would expect more from those that develop ecommerce solutions on a daily basis.

And there in lies the problem. It would appear this is a problem that is affecting a huge number of sites built with big name ecommerce solutions. We tested websites built on a number of different technologies and found the majority inaccessible. Just some examples included:

This is amazing when smaller solutions such as Shopify seem to work perfectly well without javascript enabled (based on some admittedly quick tests on my part).

Shopify website

Of course, none of this takes into account the moral or legal issues of excluding users that rely on technologies like screen readers. Personally I think it is reprehensible and I applaud our client for turning down our proposed technology. I only hope they find a better solution that does what they require and meets the needs of disabled users.

Anyway, what do you think? I have picked my words carefully in this post for fear of getting a call from somebodies lawyer! However, it strikes me as shameful that this has become an industry norm. Do you agree? Let me know in the comments below.

Update: We have been contacted by Business Catalyst

As you will see from the comments below we have been contacted by the head of Business Catalyst. They now seem to be taking a much more reasonable tone, saying that this is a problem they are intending to solve.

However this change is extremely confusing as they appear to have completely reversed their position. In the original email they said “As for BC, it will always require a browser to have JS turned on to work well, and in fact will only become more heavily weighted in that direction as we enhance the ecommerce solution.” Now they are saying “for some time now we have had plans to introduce a non-JS reliant shopping experience which as many of your users here have mentioned, should only use Ajax and JS to enhance the shopping experience.”

Which is true? Only time will tell.

  • It’s interesting to see a fundamental misunderstanding:

    “We think that losing 1% to gain 20% was a reasonable compromise”

    Suggests that the two are mutually exclusive. Clearly they are not, javascript could be used for the ajax that has been studied/proved to be good but with the fallback non-javscript working for others.

    • Not only can you cater to both of those numbers they’re ignoring the potential conversion of that 1% [or 5%]. In a world of sites requiring JS because they unknowingly implement solutions like BC, where do those with JS off [or running IE6, or other beaten and battered user segments] go? Some of that segment will surely become loyal customers of the sites that do work for them.

  • I must admit I am becoming uncomfortable at the number of sites and apps that require JS to remain usable. There seems to have been a shift over the last few years towards this way of building apps. But is it actually a problem?

    What I’m interested in learning more about is: How many users actually don’t have JS enabled, and if they don’t have it, why not?

    Where are the stats and case studies for real users without JS?

    • There are some stats related to javascript usage with screenreaders here:

      That doesn’t account for all scenarios where javascript may be off by choice, or restrictive security settings…

      Even without the accessibility argument a fallback makes common sense. Unless the developer can guarantee their js works across all browers and all platforms – at least if I browse in a browser that somehow munges the JS I can turn it off (or maybe my browser disables it due to error) and I can continue to work. Not only is there no accessibility fallback theres no failure fallback.

  • When building our eCommerce system from scratch (and all our work actually) we make a point of catering for non-javascript users.

    • So did we when building a bespoke solution for Wiltshire Farm Foods.

  • I totally agree with you Paul. I’m continuously astounded by the lack of understanding about the importance of graceful degradation among our peers. Also, in my experience, the big players are often the ones that are most ignorant.

  • I agree that this is totally unacceptable. A one page checkout may well reduce abandoment rate, but there’s absolutely no reason why there shouldn’t be a fall back for the other 5%.

    I develop my own e-commerce solution for my clients. There’s just me coding the system from scratch, and I wouldn’t dream of releasing a site that simply didn’t work without JS enabled. Why then a large company like Adobe with a team of godknowshowmany and a revenue of godknowshowmuchmore can’t manage it, is way beyond me.

  • Si

    Yep, i found this too. People demand ajax events such as ‘add to cart’ and do not want to page load.
    I see nothing wrong with this except from an accessibility stance.

    Maybe you should have pitched for this job including the information that almost all solutions require JS and asked the client to make the call.

    I am willing to bet the agency who won the job will not have brought this up.

    • But the point is you can have the AJAX and be accessible. The two are not mutually exclusive.

    • “I am willing to bet the agency who won the job will not have brought this up.”

      Which would be completely unethical, something certainly beneath HeadScape. Suggesting that would be a acceptable course of action is equally unethical.

    • Si

      Correct! i was only suggesting that you make the client aware of the issue and allow them to make the call.

      Isn’t it also true that a lot of bots can bloat the real value of people who turn off javascript? I have never come across anyone who has it turned off. Who are these people?

  • Sebastian Green

    The reply basically says none of our competitors bother with it, so why should we.

    Maybe there is a gap in the market for a similar solution that does not rely on JavaScript.

  • Of course I agree. Turning down 5% of people for no reason other than their browsing preference is ridiculous. There are so many reasons for somebody to not complete a purchase, especially online, that giving them another one seems ludicrous to me. It’s a combination of laziness and one-up-manship. Rather make something pretty looking for most than functional for everyone.

    I’ve noticed a trend lately where user experience is becoming a bigger and bigger focus though, which is great, so hopefully with the help of enlightening posts like this designers and developers will stop trying to get away with missteps like this.

  • I’m not normally given to commenting, but I am working in a small team on an ecommerce solution at the moment which has a goal of being heavily AJAX-based from day one, and this interested me more than usual. I wasn’t aware that these portals actually made special effort to exclude users without JS, as opposed to merely giving them a limited experience. We certainly won’t be making that mistake!

  • Could not agree more. 5% can mean a lot of money, especially for those big guys.

  • Couldn’t agree more Paul.

    We evaluated a number of off-the-shelf solutions recently (including Magento), and only one of them had no reliance on JavaScript for core functionality (and that solution fell short on other requirements).

    There are a number of solutions out there (Magento included) that could be re-written to remove this dependence, but no-one seems to have taken the bull by the horns and actually done anything about it.

  • We had a similar experience with BC (GoodBarry at the time).

    In charge of the rebuild for one of our projects, I evaluated Business Catalyst and found it would fit our needs. I setup pages, tested the basics of themeing, etc – typical due diligence. I recommended it and made the decision. I was wrong.

    About half way through the redevelopment we discovered that the system completely failed for users without JS. Unfortunately we did not have time to reverse course and move to a new CMS, so we wrapped it up, and promptly began development again, on WordPress.

    Their claim that the issue hasn’t come up much is utter nonsense. I complained multiple times and received completely useless responses – usually days later. Not only that, but more than one rep had the audacity to imply that we were inept when I pointed out the issue, and other issues related to JS dependency.

    The idea that it is acceptable to purposely deny access and use to users is completely unacceptable.

    In addition, areas of their sales pitch were found to be completely untrue after extended/dev use.

    As for Shopify, I am a serious believer. The team there is wonderful, smart, and the kind of people moving the web forward with semantic, well thought out behavior. They open source their developments such as liquid. An excellent group to be sure.

  • As a bit of a javascript fan boy, this one’s a difficult one for me. My geek side wants to scream at the people without javascript enabled to turn it on, but having a modicum of understanding around accessibility I know this isn’t the appropriate response.

    The response from the vendor is very surprising though, you would at the very least like to see words like “we’ll get that on our roadmap”. I hope your post gets some attention and we can see some improvement with these products.

    At the very least is has reminded me the importance of catering to all my potential users, rather than just the majority – even when a deadline might tempt me otherwise.

  • It’s appalling that they think it’s acceptable to exclude non-JavaScript users. It’s not a matter of looking at how many users have JS switched off. While the option to switch of JS exists in browsers we should be catering for that mode of use.

    It’s really not hard.

    I thought progressive enhancement was a well-known and understood concept…

  • I agree, I think JavaScript should be used to enhance the user experience but shouldn’t be relied upon for the main website functionality.

    It seems like a pretty obvious point in my mind, and screams nativity if one was to ignore such an obvious point.

    In the web industry we spend so much time making sure our sites work with IE6 (well, some of use coughYouTubecough) which is currently holding about 10% of the browser share, so why shouldn’t we also make sure our sites work in situations where JavaScript is disabled, which according to w3schools is about 5% (although this data seems a bit outdated)?

    Some of the arguments between supporting IE6 and disables JavaScript are actually the same, like in a corporate environment, where an organisation may not want to enable JavaScript.

    Seems like a no brainer to me, unless you physically control the environment of which the site / app is used (e.g. internally) make sure lack of JavaScript doesn’t cripple your site for your users.


  • I think too many developers get drawn in to what can be done to “improve” the shopping experience using Ajax and scripting gimmicks too early in the development process.

    The first step should always be to create a robust html solution. You should then be adding JavaScript features on top!

    I’ve built a few bespoke e-commerce solutions over the years and they all work without JavaScript enabled. I find staying away from JavaScript until you have a working e-commerce engine makes the development process much faster and guarantees the solution will work in browsers that don’t support JavaScript.

    • Absolutely… every feature should be built without JS, and then once it’s all working happily, srpinkle some lovely JS on top to make it look awesome.
      It doesn’t even take any extra effor that way! I just don’t get this JS only mentality.

  • I totally agree.

    It’s also worth noting that Shopify did originally depend on Javascript in the checkout.

    That was about 3 years ago, when they first launched.

    When I – and several other people – tackled them about it they did originally try to justify it with the same percentages argument.

    But – and this is why I do love Shopify – they did listen to their users in the end and updated it.

    That was all 2 1/2 years ago now .. it’s shocking to see things like Magento still haven’t caught up.

    Also, it’s illegal in the UK (at least) to use a system that prevents disabled people – which a JS dependent one potentially does.

  • 100% agree – Javascript can add so much more to an experience, give polish to your interaction and even make your user journey far easier.

    The key word in the sentence above is “add”. It’s should only be in addition to ‘normal’ interaction with the content of the site, and never be relied on.

  • I totally agree. Javascript must be a facilitation for shopping process and not a barrier. It’s amazing because technically is relatively simple to degrade gracefully a web site.

  • Completely agree, building an e-commerce solution or site that doesn’t work without JavaScript is just plain silly.

    It’s like not letting people into your shop unless they have a mobile phone on them. Just because it’s a nice technology that can perhaps improve the experience for those who chose to use it, doesn’t mean you should cut out the people who don’t use it.

    I wrote a long rant on my website last year about how JavaScript shouldn’t be relied on after I came across a website that had a JavaScript bug meaning the link to add something to my basket didn’t work. Because there was no fallback, I just couldn’t add things to my basket, even if I disabled the JavaScript and I ended up going somewhere else. Madness.

  • Great post Paul and a pity that your email wasn’t better received. The way I see it you have suggested an improvement to the product, and maybe in due course they’ll make the appropriate non-JS version.

    Also 5%… it IS a big number, when it could be 0%. It means that one in 20 people will never buy from you. That sucks.


  • Hi Paul –

    Completely agree with you re: progressive enhancement as a rule. It’s amazing to me that they would put a product out there that doesn’t work with something as simple as JS not being enabled. That’s just shocking. Further – it’s also justified by them with inaccurate information. I’ve built many sites with Drupal and Ubercart (one of the solutions they mention) and it has absolutely no requirement for JS to function. Just confirmed it now by turning of JS and spending money in a client’s online shop. Completely untrue that JS would be a requirement.

    It’s sad that they’re leaning on inaccurate information to justify lazy behavior on their part. Shame on them.



  • I’m SO tired of relying on Adobe for solutions to everything. They’re way overrated, in my opinion and have become a necessary evil in the design world. Their customer service is lacking and they always assume their customers are somehow trying to rip them off.

    That being said, I have CS3 Master edition because I HAVE to.

    I apologize. Just venting. :)

  • Looks like this is becoming more and more common where people are prepared to overlook the minority.

    I spent a disproportionate amount of time on recent project making sure that the standalone contact form I was implementing validated the users entry regardless of the JS status.

    It became very obvious that a lot of the solutions just didn’t cater for users with JS turned off.

    While this instance is not strictly a usability issue it just goes to show that the general prognosis is that its ok to create a product as long as it works for “most people”.

    To be honest I think that these people should know better!

  • Here’s how my online banking looks with JS turned off:

    • Yeah my bank (US Bank) is very similar but at least displays the home page, the error is thrown once you try to log in. Fortunately I’m in the ~95% category.

  • Three questions for the community:
    1. Why does anyone disable Javascript?
    2. Do screen readers and such not allow for Javascript?
    3. Is there any reason why blind/deaf users cannot use access Javascript?

    A real life scenario:
    It’s law in Australia, and I’m guessing most other first-world countries, to provide disabled access to public-facing businesses. A specific example would be ramp or lift access to shop fronts requiring stairs.

    This idea in theory could be transferred to E-Commerce websites, in that it could become a legal requirement to provide access to all users.

    • @Bill

      It is the law.

      Both in the UK and in Australia.

      Also, for any companies dealing with or supplying to government in the US.

      And in fact in most other Western countries.

    • “1. Why does anyone disable Javascript?”

      Security, I think is the main reason. Some users with screen readers may find the web works better with it switched off.

      “2. Do screen readers and such not allow for Javascript?”

      They do.

      1. Is there any reason why blind/deaf users cannot use access Javascript?

      JavaScript can cause problems with accessibility when using a screen reader. For example, if AJAX dynamically updates the page with content a blind user can easily miss that any content has been changed. ARIA is a tool designed to address that problem but is not yet in wide use.

  • This is where the market’s meant to come in.

    It’s up to us as web designers to spread the word about the importance of progressive enhancement.

    A few years ago, people were using similar arguments about tables-based layouts.

    Everyone else does it, you’re being too pedantic etc etc.

    If the market demands it, BS (sorry BC) will change too – and so will other people.

    We need to educate clients, and fellow web professionals, to demand that sites work (even if clunky) without JS.

    And perhaps, we should also go along to the sites like Shopify that do do the right thing .. and ask them to add the features that BC perhaps has over them.

  • OMG! I can’t still believe that magento rely on Javascript.

    By the way, I live in Brazil, and I am still looking for an e-commerce solution here build in progressive enhancement. Too bad I can’t use shopify.

  • ZzzZZzzz

    web in 2050 : website with tables, no javascript, css 1 approximately supported, 800*600 screen resolution

    Is that what you want ?

  • Ok I’m going to play devils advocate here and ask: who actually disables their JS? The ONLY time in over 10 years of being in web development that I’ve heard of someone disabling their JS were other programmers – and they knew a bunch of sites wouldn’t work.

    The average computer user barely knows anything about the web past checking their facebook and gmail accounts. I could ask everyone of my clients if they turn off their JS: half would respond “I can do that?” the other “what’s js?”.

    It’s only my opinion, but I think catering to the 1% without js is like catering to the 1% who still use IE5 and below. That being said, for other purposes such as load times, a site shouldn’t be too heavily in JS anyways.

    • There are a number of reasons to support non-JS users. One of the biggest reasons people have it disabled is beyond their control, usually in a corporate environment. I used to work for a major retailer whose intranet uses a proprietary knock-off of IE6 which had major problems with AJAX (so I would have to click the “basic HTML” link to use Gmail). Proprietary browsers are common in corporations because they control use/access/security.

      Those who intentially turn off their JS are usually those that you described, who use the internet so little that their only experience “javascript” (as they’ve been told) are the negative uses of it such as popup ads, etc. They turn it off because they think that’s the only purpose for JS and then don’t understand why the rest of the internet sucks.

      As developers we are responsible for making things work for everyone (doesn’t have to be pretty or perfect for the JS-lackers, but at least functional as a fallback).

  • Will

    The problem of 1 in 20 being unable to use your website is just the tip of the iceberg.

    Anyone else remember the old retail cliche “A happy customer might tell 3 friends, but an unhappy customer will tell 20”?

    This is particually important in the age of the social web where a negative tweet about your company could instantly give hundreds (perhaps thousands) of followers a bad impression of your company.

    • Soleone

      This point is sooo important!

  • Thanks for the post, Paul. I agree that using JavaScript as a means to enhance core functionality is the best approach and it seems clear that this was not the approach used. I’ve reached out internally to discuss this.

    To add my own thoughts to the comments:
    1) I think what would really help is what Matt Hill asks for “Where are the stats and case studies for real users without JS?” – no one wants to exclude any users, but having more data is always better for these types of discussions.
    2) There is some mention that relying on JavaScript is against the law in the US and elsewhere. Section 508 in the US does not make any such claim, and while WCAG 1.0 does WCAG 2.0 does not. There is increasing recognition that reliance on JavaScript is not an accessibility issue for people with disabilities, and that is why WCAG 2.0 includes this change. It is, undeniably, a concern for some percentage of users across the board, and that is what we need to look at internally.


    • Kahor

      This is all useless without real data about the people that disable javascript on their navigator, it might be 5% on the web but very well 0% of your business client’s.

      If those 5% are bots, advanced users that know to turn it back on when needed, and people which workplace disable javascript, you are most likely not loosing any customers (except if your customers are within the latest group ofc). I guess it’s all situational

  • Dave McDermid

    Most people don’t turn javascript off, but that is not the point. If javascript breaks on a page in IE for any reason then often all scripts will be stopped. This means your page is now broken, and a user sees this as a broken site. They may not come back.

    Another situation: if the javascript takes some time to load on the page and the user is impatiently clicking on buttons, they’ll have a poor experience.

    If the page falls back to a good ol’ form post / non-js alternative then the user can carry on with worries.

  • I think we should always think about “what will happen if JS is disabled?” and provide user with alternative.

    That’s what I do.

    For example: Is it so hard to actually put the link in “href” to the page that will do server-side version of whatever your JS funcionality would do if it would be enabled?

    That’s really not a big deal and we can be sure that EVERYONE can use our app properly.

  • While I completely agree with Paul that sites should always be progressively enhanced, I think it’s fair to point out that Adobe just acquired Business Catalyst and has not yet rolled out “their version.” As the liaison to Adobe from the Web Standards Project (WaSP), be assured that I will be adding my voice to the internal discussions where I can.

  • Who are these 1% of users with Javascript turned off?

    Surely they are not the average Joe User – you know the “I use Internet Explorer because it’s installed with my PC” type of consumer. The type of person that doesn’t understand web standards, interoperability or progressive enhancement. In short, the kind of person that spends money online.

    No, they have taken the decision to disable the technology – actually, just doing that is way above the knowledge of the average user. In my view, in doing this, they have also taken the decision to opt out of a major part of the online experience and will be well aware of the consequences.

    Crucially, though, they must also be quite capable of re-enabling the technology if they come across a site that requires Javascript and they wish to use it.

    It is therefore wrong to assume that requiring Javascript deters buyers. Indeed, the typical non-Javascript enabled user would be far too paranoid to give you his name and address, let alone any credit card details.

    • The same can be said for people who disable flash. But that’s a whole other kettle of fish! :)

    • Marcus

      Your argument holds water when referring to a techy pedant but it does not for a screenreader user.

  • Hi Paul,

    Thanks for raising this very valid issue. I head up BC inside Adobe and for some time now we have had plans to introduce a non-JS reliant shopping experience which as many of your users here have mentioned, should only use Ajax and JS to enhance the shopping experience.

    Certainly at the time of the initial development (3 or so years back) we made an incorrect decision but we’re well aware of this and hope to have this fixed in the not too distant future. We’ve always focused on valid markup since we target web designers and accessibility is something we have also become religious about in the last couple of years.

    I hope to be able to make an update here when we make the relevant changes to our eCommerce functionality.

    Bardia Housman
    Adobe Business Catalyst

    • Hi Bardia,
      first thank you for your honesty and openness here. The email we received and I have published above took a much defensive tone but your honesty goes a long way. I will make you a promise. If you get BC working without Javascript I would take great pleasure in interviewing you about the journey on the podcast. Keep me informed.

    • I must correct Bardia on his claim that BC have become religious about accessibility. This is just not true. Or if they have, they failed to implement any of their new found religion into the actual product. Sprouting rhetoric will not make your product better. Using tables to achieve design with the form builder and web app and online shop layouts will not help your cause either. As a premium BC partner, I can assure you from first hand experience that the standards built into the html of the product do not stack up. What’s really disappointing though is how their marketing and sales collateral make it look so easy to deliver complex solutions to clients. If only the product delivered what they promise. And Adobe’s purchase of them has had no positive impact on support or the product as far as I can tell.


  • Devan

    Javascript makes the checkout process more usable, if done right. Such a small population have it turned off that is just pointless to make a sight slightly more complicated just to cater for a tiny population.

    I completely agree with this statement

    “It is therefore wrong to assume that requiring Javascript deters buyers. Indeed, the typical non-Javascript enabled user would be far too paranoid to give you his name and address, let alone any credit card details.”

    • I am not for one minute that i is more complicated for anybody. You can use as much javascript as you want. It just needs to work without JS too.

    • Devan

      Wow, didn’t realize my grammar and spelling mistakes there. Note it was 4am where i was.


  • Few things.

    1) Im surprised Headscape use commercial e-commerce solutions? As you mentioned you built W. Farm Foods from scratch why not continue this trend?

    2) I would hazard a guess the percentage of users with Javascript being disabled varies greatly on the type of user they are.
    For example a site like Wiltshire Farm Foods I would persume have a very very low percentage of people with JS disabled, as it’s aimed at an elderly market.
    Where as for example a site like Dell or Apple Store would have a much higher pecentage because of their user base being alot more tech saavy.

    3) An e-commerce solution not working with JS disabled is basic failure. And it’s an approach which is becoming increasingly apparent. I’m hoping it’s just another trend because of AJAX being a ‘newer’ technology. But if this is indeed the future of the web, with no thought about backwards compatability then it’s going to cause more and more problems in the future.

    Javascript is meant for user enchancement. It is not meant to be used for the site itself, or be an integral part of the website. Build your site, get it working without any kind of Javascript layer. Then if you want to improve the experience with it enabled, do so.

    • Mike

      I agree with you on that. Another thought is that even a tech guy could have JS disabled because he may be using some plug-in such as Noscript. Sometimes he want to get something done quickly and not notice that Noscript is blocking his sites, would feel disappoint about sites who could not work simply because JS is disabled.

    • we’ve actually got a higher rate of those with JS disabled, because for al the “modern screenreaders support js” hoohaw, they really don’t, and most users have been using the same software for years, and have got used to manual refreshes, rather than virtual ones. Even if WindowsEyes supports JS, the user will probably disable it to make their life easier. We also need to take into account mobile users(not so much an issue for us!), the mighty googlebot and the application monitoring platform we use – none of which reliably support js.

      But that’s not really the point here, it’s good coding practises, separation of form and function, creating semantic markup, all the stuff we should have been doing for years.

  • Si

    Surely in this example the cost of a bespoke solution would be so much greater that a JS reliant solution that the client, upon learning all the stats, would always choose the cheaper option. After all, the majority of people shopping online do so at home with ‘normal’ security and js turned on. I have a few online shops i have built i think its time i had a deep look at the analytics!

  • Curious how many of the commenters here are themselves assistive technology users? I have been using a screen-reader for the past five years and although I do not turn Javascript off in my browser as a general practice, I do turn it off on some sites to enhance my experience. So, I believe that from an accessibility perspective the greatest barrier is badly implemented Javascript, not the existence of Javascript. I don’t know that I am the typical user, as I am also a developer. However, if I am turning Javascript off to access a site, I wonder how many other users of assistive technology are pressing the back button?

    But the accessibility argument shouldn’t matter. There may be users who choose not to use a site because Javascript is disabled, and creating a semantic, and functional, site in html and adding enhancements would seem to me to be the best design practice, with the benefit of making the development cycle easier to manage and maintain.

    • Who turns off their JavaScript? People who have only dial-up do. Recent studies show that only about half of Americans have broadband Internet in their homes. I spend time in a part of the US where dial-up is the only option. Many (most?) JavaScript dependent sites take so long to load I can’t get anything done unless I turn it off. It’s another case of how doing something for accessibility helps in other situations you hadn’t thought of.

  • Your friend (he mentions a discussion he had with you on the subject) has now written a similar article on Econsultancy:

    Matt’s article prompted the guys at Snow Valley to point out with a case study an almost perfect example of how it should be done! Despite working on a closed platform, the best practices have not been forgotten; the the key thing to mention is that the User Experience team has to be fully involved in pushing the platform and making sure that back-end developers are always fully aware of the correct approach.

    Here’s the link if you’re interested:

  • Clients like this really raise the bar and challenge enterprise vendors. It reminds us that its not all about features and that we need to give serious attention to usability and accessability.

    The lose of a project to a platform with a smaller feature set is often a big wake up call for vendors. It has been for us in the past.

  • I use NoScript to browse with JavaScript disabled for security and performance reasons; enabling scripts for specific domains when I feel that it is trustworthy and worthwhile. It generally results in a faster and less intrusive browsing experience. When you are opening literally hundreds of web pages every day you notice the difference and you can quickly tell when the front-end a website has been well built or not.

    What is remarkable is that the “money talks” philosophy hasn’t prompted more ecommerce solutions that don’t rely on JavaScript. If someone can’t be convinced by the moral or legal case for accessibility they will usually listen to the “you’re losing 1%-5% of your potential customers” line and see it as a reason to make changes.

    The revealing part of your article is actually the response to your concerns. I was amazed to see a representative of a professional ecommerce solution dismiss issues of JS-dependence, especially when their product affects the profit margins of businesses and discriminates against people based on their abilities or web browsing environment.

    Progressive enhancement is best-practice development. You cannot assume that scripts will be enabled or will even be executed properly. Ecommerce websites are an area in which the quality of development can have measurable financial consequences.

    Hopefully your measured public criticism will help shake things up a bit and remind people as to the importance of inclusion and progressive enhancement.

  • Keith Humm

    While I wholeheartedly agree in concept with the progressive enhancement philosophy, it isn’t always that simple.

    When money is involved, some things have to get cut. Budget just dictates it, and more immediate concerns are always available.

    Sometimes developing in non-js first, then tacking javascript on top just doesn’t work well. You have to factor it in from the beginning for a well architected solution.

    It’s no excuse, but it’s easy for me to see why one wouldn’t bother.

  • paul

    Why does a customer block javascript? Because of security – he does not know if he can trust the site he is visiting. Fair enough. So why is he about to bang in his credit card details to this same site he might not trust????

    It’s the same with cookies and other ‘privacy’ issues, and as web designers we should educate users about real risks and not pander to the ego of those with just enough knowledge to allow them to do stupid things like turn features off.

    Case in point – cookies. Many users turn these off, probably the same ones who turn of javascript. Apparently this is because cookies are a ‘security and privacy risk’. Right. So for cookieless sessions you need to pass session IDs around in URLs (remember – no special javascript links allowed). And then your ‘privacy concerned’ customer just copies the URL of something he just viewed to a forum, session ID and all. And next thing, you’ve got complaints from the site that users are hitting it and seeing other people’s baskets and details.

    And don’t think you can put an IP block on sessions, to prevent this happening. Because then you’re excluding AOL users, whose IP changes on every page thanks to the bank of proxies AOL uses.

    So a carefully designed system to run cookieless sessions because of a few users’ privacy concerns end up allowing clueless users to publish their sessions publicly.

    As web designers we should stop pandering to these people. If they are concerned about security, run Firefox with no-script and activate it on any site that they are willing to give a credit card number to. If they are on a browser like IE6 that does not make it easy to switch javascript on and off, then they clearly don’t care much about security anyway.

  • Alex

    Good article and some very good points. I’m bringing this up with our software providers (Venda) next Friday when we have what they call a ‘value added open day’, I checked the checkout process last night and I can’t go beyond the basket unless JS is enabled, considering their platform is built on Perl submitting forms should be serverside not in the browser.

    I’m ashamed this is the first time I’ve noticed this and I’ve been using their platform for 3 years. hangs head

  • Ben

    Disabling JavaScript was so 1997. Anyone that does it is an idiot. And to be frank, I don’t want to sell anything to idiots. Besides only 0.09% of our users have JavaScript disabled, so I think this author skewed the numbers so they’d have something to blog about.

    • Not everybody has an option to enable Javascript. As for my figures they come from W3C School. Have you considered that your figures are low because they cannot access your site.

    • joe

      i’m with ben on this one. i’d be more concerned with quirks mode on ie8 being so close to the ‘go’ button if you’re concerned with stupid users.

  • I left a comment on the Audioboo, but I’ll just reiterate it here so it’s included in the actual conversation:

    I don’t normally weigh in on stuff like this, but I have to say I disagree with this stance. I would agree that if you are building an HTML site you are best to use JavaScript to progressively enhance a server-side process. But that also fails to acknowledge that there are things that server-side processes and standard HTML simply cannot deliver.

    Two examples would be Google Maps and Flash sites. One could make an argument that these are not valid, and that because they aren’t accessible – since they rely on proprietary technologies and not the most common denominator – that they shouldn’t even exist. I think this fundamentally rails against the notion of the choice of expression that the web provides. Surely, yes, encourage people to not use a proprietary technology when the same can be achieved with accessible methods. But to say that all sites, no matter their use, audience or content should be delivered with server-side processes and HTML only (with bolt-on enhancement) is, I believe, flawed thinking.

    I would add a caveat here that if a site has been funded by public money for, say, a government site, I believe it has a duty to be delivered for the people who paid for it, which will actually mean building specifically for maximum accessibility. But to try and apply that stance, legally or technically, to all sites on the web has the potential to stifle creativity and freedom of expression

    • I think it’s safe to say that Google Maps is an exception to this rule (however, go ahead and go to Google Maps with JavaScript disabled. It’s heavily limited but functionally works (in that there’s no errors, and allows you to view the maps… but doesn’t let you ask for directions)).

      The important thing with this particular blog post though is that he’s talking about an Ecommerce solution, something that can (and should) very easily be implemented with no JavaScript and still maintain usability. Javascript can then pretty easily be added (not just “bolt[ed]-on”) to improve the overall experience of the majority who gladly have access to Javascript (which, as I mentioned in another reply is not always the case thanks to many corporate environments).

      It isn’t (and should never be) a law that requires compliance on EVERY website, but when doing business it’s critical to at least keep accessibility (regardless of the “disability”) in mind.

  • Zencart does not require JS for checkout as far as I am aware.

    So what is the best opensource solution?

    Each cart seems to have problems

  • Michael

    I can’t fathom the arrogance of some of the web designers commenting here. If only 0.1% of your customers have Javascript disabled, that is because at least 5% of your potential customers gave up on your web site.

    So many people have been scammed in so many ways lately, and it’s so much in the news, that they are getting increasingly wary. Expect the number of users who disable Javascript to start rising sharply.

    Meanwhile, why should I trust a web site that it sleazy enough to require JS in the first place. You people are helping me cure my Internet addiction. The more web sites that insist that I disable my security settings, the more time I’ll have to read books and go outside in the fresh air and get some exercise.

  • I’ve happened across this excellent post several weeks late and totally agree with its sentiments. I found myself in a similar position last year with Magento but, with regret, was obliged to press ahead with it.

    Like Nicolas Gallagher above I’ve taken to browsing with NoScript and it has been an illuminating and dispiriting experience. Dispiriting because what has struck me particularly of late is that progressive enhancement being overlooked is not especially a problem with e-commerce – it’s to be found everywhere and in some unexpected places.

    Pretty much daily I find myself following some web dev related link to a site that has something interesting to say and looks fantastic, only to find that significant chunks of said site, and sometimes the whole thing, are completely inaccessible due to JavaScript dependence. And this is happening on sites that include those belonging to web design businesses and individuals who make a point of touting their ‘ethical’ approach to web design!

    More often than not, a bit of digging reveals that this is down to lazy (or unthinking) implementation of jQuery. The irony is of course that jQuery makes it really easy to do things right, but it seems that increasingly even some professionals who ‘talk the talk‘ just can’t be arsed.


  • It’s not just progressive enhancement that eCommerce packages get wrong. I’ve always found this area incredibly frustrating when you spend time installing and evaluating a piece of software to find that it does stupid things. Like using full size product images as the thumbnails, resizing them only in the browser (great for multi-megabyte listing pages). Or having a non-functional checkout process in a 1.0 release (with or without JS).

    Choosing an eCommerce system is pain.

    Btw, Paul (3/3/10) — I think you make some good points.

  • James Gaunt

    I totally disagree with most comments here. Javascript is a core technology of the web. We left behind the world of static pages or full page post back years ago… why should we continue to hold back and slow down development for a mere fraction of users?

    The 5% figure is bogus, maybe 5% of web queries come from non javascript enabled devices, but that is not the same as saying 5% of real (i.e. sentient and likely to pay) visitors to e-commerce sites have JS disabled.

    This is the same argument that we should be doing more to make sure people who are too lazy or ignorant to upgrade their browser in the last 7 years can access the site…. maybe we should be bending over backwards so people who haven’t even got the intelligence to turn the PC on can still use the web… anyone care to make up a figure for what % of customers we lose there!!

  • infradawn

    As designers we have limited control over the capabilities of the devices that render our efforts. The limits of those capabilities are often determined by feature sets which are archaic, flawed, or simply user disabled. And while it is laudable to speak of designing to a baseline that accommodates as many of these disparate client environments as our conscience requires, that baseline moves inexorably forward as technologies become established.

    eCommerce is a revenue channel subject to the same economics that underpins all business activities. Just as the advertising budget seeks to deliver maximum bang-for-buck by understanding and exploiting the customer demographic, so too the eStore. Part of requirements capture is to fully understand how the customer is reached, how they are engaged, and how they are retained. This is no place to define arbitrary functionality thresholds under the banner ‘progressive enhancement’ or any other. Bang-for-buck is rarely increased by adding unnecessary resiliency and the CEO may not embrace as passionately the increased cost of providing it as you are committed to delivering it.

    Target your customer demographic. Period.


  • infradawn

    As designers we have limited control over the capabilities of the devices that render our efforts. The limits of those capabilities are often determined by feature sets which are archaic, flawed, or simply user disabled. And while it is laudable to speak of designing to a baseline that accommodates as many of these disparate client environments as our conscience requires, that baseline moves inexorably forward as technologies become established.

    eCommerce is a revenue channel subject to the same economics that underpins all business activities. Just as the advertising budget seeks to deliver maximum bang-for-buck by understanding and exploiting the customer demographic, so too the eStore. Part of requirements capture is to fully understand how the customer is reached, how they are engaged, and how they are retained. This is no place to define arbitrary functionality thresholds under the banner ‘progressive enhancement’ or any other. Bang-for-buck is rarely increased by adding unnecessary resiliency and the CEO may not be as enthusiastic at the increased cost of providing it as you are committed to delivering it.

    Target your customer demographic. Period.


  • Anonymous

    I can’t leave a comment without having JS turned on .. oh the irony! ;)

  • Anonymous

    Thanks for sharing this wonderful information. It’s just too good.

  • Fake name

    Funnily enough I stumbled across this site when reading a thread about how to access disqus without javascript (as a user – you can’t do that easily)

    However – to weigh in on the “who disables javascript?”, I do (and enable it whenever a site warrants the effort) for reasons of performance.
    I’m right now typing this on my cellphone ans notice this is tab 75, care to guess how many tabs I have open on my desktop… (it varies – currently 34, but I ebb-and-flow with about 80 tabs over the course of a day, when studying something or shopping the ebb-and-flow often goes past the 250tab mark)

    And I normally notice I have forgotten to turn javascript off us that syddenly everything becomes very slow, I have to clicks a few crapload of buttons to read an entire page, endless hell (sorry, scroll) appears and lots of unwanted things happen (completly wrong suggestions when typing, sluggish input-boxes, reloads if pages while typing (add a 0.2s delay after last key entered before searching, please])
    I actually have a permanent site-specific setting to disable js on * for that reason (the site work better without js)

    And yes, this site warrants loading javascript to leave a comment but it would have been nice with a line informing me I have to do that (btw, thanks for setting it up so one could read without js on)