The horror, the horrorYou would think with the money spent on e-commerce platforms today, that best coding practices, accessibility and SEO readiness would be at the forefront of developer’s minds.

However, it transpires, for a number of platforms, getting the basics of Javascript has gone awry.

Last Friday I had a call from Chris Scott of Headscape, one of our usual weekly chats about current projects, but this week he brought something to my attention. Headscape recently pitched for some e-commerce work, and Adobe’s Business Catalyst was to be the platform of choice. However, one of the pre-requisites was that the site work when Javascript is disabled.

The reason for this being that that the company had many customers with disabilities, and for blind visitors using screen-reading software, Javascript support (specifically on AJAX content updates, where the user is informed that a “virtual refresh” has taken place) doesn’t always give the best experience.

Well, it transpired during their demonstration that Business Catalyst sites require javascript to be turned on, and, as you would expect, when Headscape mentioned this issue, they lost the pitch.

So, Chris was discussing this with me, and I was saying “No! Really? Well why didn’t you suggest they go with Magento or Demandware or something like that?”  Upon which Chris tells me that Business Catalyst mentioned Magento when he contacted them about this, as one of the platforms that also requires Javascript to function.

Reiss Homepage without JavascriptTo which I sit, aghast. “What? No, oh come on, what is this, 1999? They may as well have a Flash intro and an exploding logo” I joke. We then go on to test a bunch of Magento sites. Reiss, Jigsaw, Salter, even the great MyDeco. None of them worked. Some you can get further than others  – Salter I could get to the checkout before hitting an obstacle, Reiss I couldn’t get past the homepage.

Salter Checkout without javascript

So OK, fine, I’m shocked, but fine, Magento’s out. Let’s try Demandware. We go onto a few Demandware sites, Crocs, Timberland, House of Fraser, none of them work without Javascript. The crucial add to basket button is disabled turn out not to be a button at all.

So Demandware’s out (utterly astonished here), what about ATG or Hybris? Well, looking at Speedo, Toys R Us and Long Tall Sally, they all have the same issue. B&Q’s, running off of ATG, had some weird issues. In some sessions we could add products and check out, in others we couldn’t.
B&Q error Message

In our investigations we only found a handful of platforms that didn’t require Javascript at all to place an order, including at the high-end, IBM’s Websphere Commerce and at the low end, good old Shopify.

So, what’s the big deal? Everyone has Javascript?

Well, you see, I come from a land where no development even gets past wireframing until we answer “OK, but what happens when Javascript is disabled?”

Why do we do this? I mean, javascript is pretty much in every browser. Why would Javascript be disabled? Am I saying we shouldn’t use Javascript at all?

No, I love all things type=”text/javascript”. You know that awful flash carousel on – we’re totally about to replace it with a Javascript version.

What is deeply wrong is where Javascript is used to create the base functionality of the site, that’s just not how things should be done nowadays. Let me show you how things are meant to be:

Progressive Enhancement

Progressive enhancement was a term coined by Steven Champeon at SXSW, as a reverse practice to Graceful Degradation, which says to create an all singing-all dancing website first, then remove features as you go down the browser list in terms of what they can handle.

However, frankly, this is an arse-backwards way of doing things. Progressive enhancement is the way to go.

What progressive enhancement requires is that you first build your website in bog-standard semantic html first. That buttons are buttons and links are links. Your markup validates and all your website functions work in any browser that understands HTML4.

You then style everything us using CSS, and add unobtrusive Javascript functions to do all the cool Ajax/Jquery cool 2.0 stuff. If the browser being used doesn’t understand the particular bit of CSS or javascript, it doesn’t matter, because the “base experience” is still usable.

Well, that sounds terribly by-the-book, bet it’s expensive.

Well it’s not. It works out more cost effective, not only because you can pick and plan the implementation of bolt-ons to the base experience, but also, when you’re testing any new functionality, presentation (CSS), logic (Javascript) and data (HTML) are neatly separated, making any issues easy to track down and fix.

But that’s not all, apart from the accessibility issues that having unnecessarily escalated browser requirements can have (see the recent Econsultancy post with some scary numbers), and that you can be sued for discrimination, there’s plenty more reasons. Dave McDermid from Headscape explains:

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 without worries.

Furthermore, you can’t guarantee at all that your visitors will be on a device that fully supports Javascript, especially with the push to mobile – remember not everyone has an iPhone. Even worse, your single most important visitor, Mr Googlebot, is using the worst browser ever.

If you don’t cater for Mr Googlebot (for example, loading navigation in using Javascript, I mean, who does that, really?) then you’re turning away a VIP. The same goes for any performance monitoring tools you’re using, they all use rubbish “browsers” that only understand the basics.

OK Matt, so what’s the solution?

I realize I’m doing a bit of pulpit thumping here, but come on now; this is nearly table-based layout levels of dumb.

Fortunately, since all this came to light, Business Catalyst have let us know that they’re on the case

Certainly at the time of the initial development (three 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 year

As website owners, we have to understand the technical aspects of how our sites actually work. We must have the knowledge and the will to enforce good architectural practices within our developer teams, which, from my delving into the code of some pretty big sites, seems to have utterly gone by the by. Gentle reader, in the last couple of days I’ve seen code that made me shiver.