Progressive Enhancement and Graceful Degradation: Making a Choice

Tweet

web layersIn my previous article, we discussed graceful degradation and progressive enhancement — concepts that can help rich web applications support more browsers and have a wider reach. To recap:

  • Graceful degradation is the practice of building an application for modern browsers while ensuring it remains functional in older browsers.
  • Progressive enhancement is the practice of building an application for a base level of user experience, but adding functional enhancements when a browser supports it.

Good accessible web applications are likely to use a combination of both approaches. It’s possible a feature could end up at the same point no matter which practice you adopted.

Assessing Your Application’s Accessibility Requirement

Creating a web site or application for all browsers is obviously an ideal situation. However, constraints will be introduced by your schedule, budget, and feature set. You should also be aware of legal issues arising from accessibility legislation such as the US Section 508 and the UK Disability Discrimination Act. It’s advisable to plan your accessibility requirements from the start.

There are a few exceptions; your application might so dependent on scripting or plugins that it makes little sense to cater for older or incompatible systems. For example, an online video editor would almost certainly need Flash, Silverlight, or a similar technology; an HTML-only version would not be viable.

Many developers argue that their web site or application is browser-specific and need only support that application. For example, Mozilla add-ons could be inaccessible to non-Firefox users. However, the site that hosts Mozilla’s add-ons directory works well in most browsers:

  1. Mozilla are supportive of web standards; they have no reason to create a Firefox-specific site, and
  2. a user with another browser might visit the add-ons page to find out more about Firefox. Blocking that user or providing a poor experience would not endear them to Mozilla.

To the other extreme, there are e-commerce sites such as Amazon.com. The company could lose thousands of dollars if they restricted access to any users.

Choosing Your Development Approach

In my opinion, graceful degradation attacks the problem from the wrong direction. Progressive enhancement normally offers a more logical approach:

  • It enables you build a stable application with solid foundations that should work on any device.
  • You can add further enhancements as new technologies and browsers are introduced without changing the core functionality. On the contrary, graceful degradation requires a browser support list; you might need to update the application as new browsers are introduced.
  • Enhancements allow the user to achieve an objective quicker or easier but they are not a prerequisite. For example, a JavaScript slider might allow a user to rapidly choose a number but that value would feed into a standard and accessible HTML input box.

There are a few exceptions when graceful degradation might be suitable:

  • Cosmetic issues are usually acceptable if the system remains usable. Older browsers have more limited CSS support — layouts can be different or ugly if the core functionality remains operable.
  • A complex visual application such as Google Maps is so dependent on JavaScript that an entirely different system has been developed for users without it. That’s not to say Google Maps couldn’t be achieved with progressive enhancement, but I suspect it was simpler and more cost-effective to create two separate applications.

In general, progressive enhancement should offer better stability and browser support. The initial development costs are higher but the application should require less long-term maintenance.

Coming soon: A series of articles showing how to build a simple widget using progressive enhancement techniques.

View part 1: Progressive Enhancement and Graceful Degradation: an Overview

Related reading:

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://autisticcuckoo.net/ AutisticCuckoo

    I definitely agree that progressive enhancement is preferable to graceful degradation. If you think things through properly before you start, building with progressive enhancement adds very little, if any, extra work. Graceful degradation, on the other hand, is like retrofitting accessibility: difficult, tedious and expensive.

    Of course there are certain types of applications that cannot work with nothing but HTTP and HTML support. But most normal sites and applications can.

  • Hamran

    Graceful degradation is obsolete. Hardly anybody ever made it work. Progressive enhancement is exactly the same thing, but just upside-down. They aren’t 2 approaches you choose from or use a mix of both. Progressive enhancement literally replaces graceful degradation to accomplish the same thing.

    The reason progressive enhancement works is because of the way Web code is structured: basic HTML plus optional CSS and optional JavaScript. You build the basic version of your site in HTML only, and it should be 100% functional in HTML only. The user can get at all the content, they can enter text in the Search box and click go and see a page of search results, they can do all the things that you need to do on the website. Whatever feature you add, you first add it to the HTML and it has to function there without CSS and JavaScript. I test this by literally removing the CSS and JavaScript files from a website and running it in my browser. It should still work perfectly.

    Once you have a perfect HTML-only site, you add CSS and JavaScript in a completely optional way. You don’t use methods unless you test for their existence first. You add event listeners and hijack link clicks with JavaScript. You have the freedom to add a thousand things because they are all optional.

    With graceful degradation you are working against the way Web code is structured. You’re thinking of the combination of HTML/CSS/JavaScript as 1 and you’re trying to come up with less-than-1 to work in HTML only. With progressive enhancement, the HTML is 1 and the HTML/CSS/JavaScript is more-than-1.

    So I don’t recommend you do both approaches, or even consider any graceful degradation. Build essential HTML and optional CSS and optional JavaScript. Done.

  • ranmeriaz

    A frequently overlooked solution is to use an Ajax framework that takes care
    of cross-browser compatibility and other low-level details.

    This moves the development to a much higher level of abstraction, and can cut down development time quite dramatically.

    For example with Bindows (http://www.bindows.net) you get browser compatibility for everything from IE 5.5 to Safari 4, plus Section 508 accessibility support out of the box.