Progressive enhancement is a barrier to progress
HTML5 makes it possible to build applications in the browser that were previously unimaginable. Drew Neil believes that to do so, we must first abandon progressive enhancement
In recent years, the promise of HTML5 has driven the rise of JavaScript. Browser vendors have escalated their arms race to create the fastest runtime environment. As a result, JavaScript has become too useful to be considered an optional enhancement. It's an essential component in today's web stack.
What if a web application depends on the canvas element to render graphics? What if it requires websockets to provide real time messaging? For most web pages, these features may be considered optional, but for some web applications they are the very raison d'etre. Like a tripod, the modern web stands tall on three feet: HTML, CSS and JavaScript. Take any one away and it all falls flat.
You must be at least this high to ride
In native applications, and gaming in particular, it's commonplace to list system requirements: the minimum specifications of operating system and hardware that are necessary to run a piece of software. Why should it be any different for web applications?
HTML5 technologies such as canvas and websockets make it possible to build applications in the browser that were previously unimaginable. In such instances, it's reasonable to state that JavaScript is a system requirement. When graphics are generated programmatically they can be animated. They can respond dynamically to events triggered by the user. If we throw websockets into the mix, the graphics could respond to events triggered by other users, somewhere else on the internet. The potential is dizzying.
To provide a dynamic experience such as this requires JavaScript. There's no way that a static page can be expected to provide a satisfactory fallback.
Stop worrying and learn to love the <body/>
Modern JavaScript engines are now so capable that we can demand more from them. We can move HTML template rendering from the server to the client. Instead of using JavaScript to massage data from one part of the DOM to another, we can bind our templates to client-side data stores. Any changes to the data will be reflected instantly in the DOM. A number of MVC libraries use this approach, making it possible to build maintainable large scale JavaScript applications.
Taking the client-side template rendering approach to its extreme, we end up with an .html document that contains one JavaScript, one stylesheet, and a self-closing <body/> tag (in fact, even the <head> and <body> tags are optional!). This may seem barbaric to those schooled in classical progressive enhancement, but it will feel more familiar to anyone with a background in native application development. And let's make one thing clear: web applications are in direct competition with native apps.
The case of Google Maps
Google revolutionised online mapping when they introduced the 'slippy map' interface of GMaps. Today, we can use progressive enhancement to embed a GMap on our own web pages, but it wasn't always so easy. Consider this timeline:
- February 2005 – Google Maps was released
- June 2005 – Google Maps API was released
- February 2008 – Google Static Maps API was released
Web developers had already been embedding slippy maps on their web pages for almost three years before Google released the Static Maps API. Up until 2008, if you wanted to embed a GMap using progressive enhancement, you would have to look elsewhere to source a static map image.
Can I get a show of hands from developers who didn't bother? I'm unashamedly guilty.
Google brands the static and slippy GMap APIs as two distinct products, but I consider them to be two faces of the same service. The static maps API is a feature of GMaps. A feature that allows us to provide accessible GMaps to our users without JavaScript.
Accessibility is a feature
The web is composed of documents, mostly the written word. Accessibility comes practically for free, but only because of the intrinsic nature of text, and the accessibility features of the software with which we consume it. Since text documents are so readily accessible, we've come to think that everything else should be too.
Applications and documents are different. Accessibility is not a right; it's a feature. The first features to be implemented are the ones that define an application and determine its success.
Would Google enjoy such dominance in the online mapping space today if they had focussed on accessibility over dynamism? Someone else would have been first to market with a slippy map interface, and today we would know it by another name. GMaps succeeded because Google focussed on solving the problem well, rather than solving it twice.
The sacred cow
You won't find many people boasting that they've abandoned progressive enhancement. After all, nobody wants to be caught desecrating the sacred cow. But people are doing it today.
Consider Trello.com from Fog Creek. Joel Spolsky says:
"The business goal for Trello is to ultimately get to 100million users. That means that our highest priority is removing any obstacles to adoption. Anything that people might use as a reason not to use Trello has to be found and eliminated."
Trello wants to remove all obstacles to adoption. That's interesting, because if you try to use Trello with JavaScript disabled, you'll be served a blank page. Presumably, Mr Spolsky doesn't believe that this will prevent Trello from attracting 100million users. It's a brave new web.
JavaScript is driving change
HTML5 expands the potential of web applications, creating new opportunities for businesses. First movers will have the advantage. I believe that those who insist on putting JavaScript in the passenger seat will fall behind. In this time of change, JavaScript is the driver. That's progress.
Picture of Drew taken by Lena Ganssmann.
Designer and developer Jim Newbery doesn't quite agree with Drew. Read his response, Progressive enhancement is more relevant than ever, and let us know what you think below, in the comments.
11 comments
Comment: 1
Comment: 2
Really? Are we still thinking like this?
I've watched the web community spend years working for good standards and improved access for people with disabilities, and when I read this kind of thing it really disappoints me.
Javascript and all sorts of other emerging web technologies can work so well in tandem with progressive enhancement, providing granular and selective control over content and features for different display and input devices. Not everything needs to be implemented, not everything needs to work the same. But by excluding accessibility as a feature entirely, you exclude the people who rely on accessibility standards and progressive enhancement to navigate the online world.
By taking the view that accessibility is just a feature, you're saying that people with disabilities are just not important. In my view that's a very dangerous standpoint.
Comment: 3
While I'm a big fan of your screencasts and presentations, I'm not sure I can agree with you here. Not only is Accessibility a right (and a law in many cases here in the US, specifically when dealing with Federally funded websites. See: Workforce Rehabilitation Act of 1973. ), but it's generally a low cost element to implement when dealing with text and aria-roles.
Obviously the example that you cite here: (a Google map,) is one that is specifically challenging for assistive technology and probably of little use in that sense.
I think I get what you're trying to say, but I don't think it's as cut and dry as you might make it.
Comment: 4
It's a bit harsh to say, but in practice it's seems (!) valid:
If we can discard a part of users because they don't use a modern browser that doesn't support this/or/that new technology or standard then we might as well discard people for any odd reason that lowers their experience of our suberbly awesome websites.
Not having color-vision or not being able to hear sound is as bad as not having WebGL or CSS3D or whatever. A proper browser is just the start of your technology stack that builds on your natural capabilities: why have 32bit color if you cant see red anyway?
(i'm being bashfull to make the point to illustrate discarding people is tricky).
Comment: 5
JS templating is nice, but do you have that horsepower on mobile? Maybe on the latest iPhone or Android, but not on Joe Sixpack's $10 phone with a 200MHz single-core and a Bill Gates' worth of memory (640K).
Accessibility is not a feature. There aren't, like, three colorblind people over there who don't really use the web anyway. There are a LOT of people who rely on web sites to be interpretable by a wide array of assistive technologies. Not just screen readers either.
How well do search engines crawl your JS-generated site? All of your Google referrals will come from shallow people, since all they're looking for is a .
So go ahead and build an app that requires all of those things. Build something with Facebook levels of appeal, and see if you can get Facebook levels of visitors. (Spoiler alert: you won't.)
This article reminds me of the "we don't need semantic markup" semi-flamebait on Smashing Magazine not too long ago.
Comment: 6
Comment: 7
Suppose that we have an audio resource containing an interview. To make that accessible, we could transcribe it, and publish the text transcript alongside the audio file. That's extra work. Not everyone has the time or budget to go to such lengths.
Now suppose that we have an audio resource containing music. How can we make that accessible? We could transcribe the notes into a musical score, and publish that alongside the audio file. Not only would that be extra work, but it would be practically fruitless.
While the written word is accessible to anyone who understands the written language, a musical score is only comprehensible to those with the requisite training. People who can't hear music are much less likely to have that training (there was only one Beethoven). The fact is, some content cannot be made accessible to some people.
With the HTML5 audio tag, we can now embed sounds into our HTML documents. But that is only the tip of the iceberg. I see no reason why it shouldn't be possible, one day, to build something like GarageBand in the browser. A complex application such as GarageBand would be worthless without JavaScript.
Comment: 8
As a case in point, I have been fully blind since 1994, and this didn't stop me from building WhatSock.com and the AccDC API to specifically address these issues by creating a fully accessible dynamic environment and resource for developers.
Comment: 9
If you have an audio resource containing music, then there's no way somebody who is totally deaf can experience it in it's audio form. But through progressive enhancement, you can provide a thorough description of what that piece of music is, who composed it, how long it is, what style of music it is, the lyrics etc. Some of that might already accompany the audio, so minimal progressive enhancement might be needed.
As for audio which includes spoken word: yes, you could transcribe it and you'd need to weigh up the overheads in order to do that. But you'd not just be scoring an accessibility win, you'd also be providing loads of really useful, relevant search engine juice and an extra resource for your visitors who prefer to read rather than listen, or who own a computer which doesn't have speakers. Many people crowdsource transcripts too, and over time transcription will become more automated: YouTube's automatic captioning is pretty rubbish right now, but over time will improve.
As for your point about a Garageband app. Why shouldn't keyboard navigation allow someone who is blind make music just as competently as someone with good vision? Javascript can be accessible too.
The point I'm trying to make is: don't view accessibility as a black-and-white issue: it a very nuanced subject.
Comment: 10
I can see your point (you can run sophisticated applications within the browser), but I don't really think that it follows that accessibility is a feature (and by implication optional).
You can run sophisticated accessible applications within the browser, with javascript.
Comment: 11
I do agree that we need to view rich web applications differently to simple websites. Applying the same rules and standards to both cab be prohibitive, as they are very different implementations of similar technologies.
Accessibility is the sticky issue here. Minimum technology requirements for web apps is perfectly reasonable as long as the business model supports ommitting a percentage of potential users from your target audience. Ommitting users who rely on certain technology, due to disability, is not so cut and dry and has ethical implications.
I admit I have built web applications that do not function without JavaScript. That was a decision that was made on a project by project basis. Potentially doubling the development time and costs of a project and limiting the "richness" to cater for a very small percentage of target users simply isn't always viable, despite how unethical this may seem. Common sense has to apply based on what you are building and for whom.