Progressive Enhancement and Graceful Degradation: an Overview

web layersIn this article, I will discuss progressive enhancement and graceful degradation — two concepts that are well known but perhaps a little misunderstood.

The Web is Evolving

The web is in a continual state of flux and evolves at an alarming pace. Technologies and techniques rise and fall. Today’s Safari 4 is tomorrow’s IE6. We want to use the latest advances and provide a better experience for our users.

Unfortunately, there is no way to force browser upgrades. Companies and individuals will not necessary change their working environments because of developer demands. Many people are happy to access web pages in total ignorance of the underlying technologies or valid reasons to upgrade. OS and browser manufacturers have some influence, but web developers can only extol the benefits of newer browsers.

Many developers argue that there is little sense supporting outdated technology. However, that attitude is unlikely to convince clients who want the largest possible audience or have users who depend on older browsers. Those users might not have system permissions, financial resources, or the technical ability to upgrade. Some users may be using specialist assistive technologies which cannot be upgraded. No one can force software or upgrades on a user: doing so would be contrary to their democratic right of choice. How would you feel if someone forcefully installed software on your PC claiming that it was for your own good?

The web was designed to be used with any device at any location. All we know about end users is that they are using a browsing application which transmits and receives data using internet protocols. We cannot make assumptions about their setup or technical ability.

This makes the web a hostile development environment. The applications we develop can be fragile when they are accessed by a user with an 8 year-old browser with disabled JavaScript and no plugins.

The Need for Accessibility

Accessibility is an important issue clouded by the perception that it’s just about political correctness, alt tags, or blind users. It’s far more. Accessibility is about supporting all users no matter what browsing technology they use.

A website that works on a wide variety of devices, screen readers, PDAs, mobile phones, game consoles, and connection speeds will have a wider reach than one that does not.

Graceful Degradation

Graceful degradation is one solution. It is the practice of building a web site or application so it provides a good level of user experience in modern browsers. However, it will degrade gracefully for those using older browsers. The system may not be as pleasant or as pretty, but the basic functionality will work on older systems.

A simple example is the use of 24-bit alpha-transparent PNGs. Those images can be displayed on modern browsers without problems. IE5.5 and IE6 would show the image, but transparency effects would fail (it can be made to work if necessary). Older browsers that do not support PNG would show alt text or an empty space.

Developers adopting graceful degradation often specify their browser support level, e.g. level 1 browsers (best experience) and level 2 browsers (degraded experience).

Progressive Enhancement

Progressive enhancement is similar concept to graceful degradation but in reverse. The web site or application would establish a base-level of user experience for most browsers. More advanced functionality would then be added when a browser supports it.

Progressive enhancement does not require us to select supported browsers or revert to table-based layouts. We choose a level of technology; i.e. the browser must support HTML 4.01 and standard page request/responses.

Going back to our image example, we might decide that our application should be functional in all graphical browsers. We could use a lower-quality GIF images by default but replace them with 24-bit PNGs when the browser supports them.

View the next post: Progressive Enhancement and Graceful Degradation: Making a Choice

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.

  • madr

    Good article. A bit short, but still a very important subject. Especially progressive enhancement is rarely heard of these days since Ajax/jquery fanboys tend to stick to (poor) graceful degradation if they care at all about people not haveing all their scripts demands.

  • http://nicholasorr.com SoreGums

    No one can force software or upgrades on a user: doing so would be contrary to their democratic right of choice.

    True, users choice to use my website or not :)

    At the end of the day it comes down to compromises.
    Also it doesn’t take supporting 100% of the internet users to be successful…

    I like the idea of progressive enhancement, however it usually means doing things more than once. Example, an ajax form in ExtJS. It is much quicker to start with an ExtJS form and get results on the screen, compared to doing it all in html and apply the ExtJS to it afterwards. Remember there are backend codes to write as well…

  • http://www.optimalworks.net/ Craig Buckler

    @madr
    Don’t worry – there’s more coming soon!

    @SoreGums
    Unfortunately, doing things more than once is inherent in web development, e.g. input should always be validated server-side and preferably client-side too.

    I will discuss Hijax in a later article.

  • karl

    We practice Graceful Degradation and Progressive Enhancement in all our projects. It’s extremely important when considering the time it will take to develop components on older browsers.

    We recently launched a project with an apparent ‘strong IE6 user base’. We decided to degrade the tricky components for IE6 since budget and time didn’t allow the extra work. Turns out IE6 users account for 5% of our over all visitors. Money, time, stress and sleep – all saved!

  • bevan

    Good article, is it just my old browser (safari 4) or are there some unnecessary line brakes in this?

  • http://www.brothercake.com/ brothercake

    Unfortunately, as I just noted in the ARIA post, assistive technologies fall through the net of progressive enhancement becayse they are script capable devices, and pass all the same object and features tests as the browser they sit on top, but still they don’t provide the same level of interactive capability.

    The thing to do to provide the best accessibility is to offer users an explicit choice of scripted or non-scripted interface (though you’d word it a bit better than that!), and for the non-scripted interface generate the pages so they simple don’t have the script includes.

  • http://www.pageaffairs.com/ ralph.m

    I like to test sites by turning off JS, CSS, Flash etc and see what the result is. If the site still presents the main information in a clear and usable way, with a logical flow, I’m happy.

  • the.peregrine

    brothercake said:

    The thing to do to provide the best accessibility is to offer users an explicit choice of scripted or non-scripted interface (though you’d word it a bit better than that!), and for the non-scripted interface generate the pages so they simple don’t have the script includes.

    With all due respect (and I always respect brothercake’s opinions), no, no and no. Carefully structuring a site with progressive enhancement in mind, there is no need to set up a secondary interface that requires us to maintain two side-by-side presentations of the same data.
    That’s really one of the huge advantages of progressive enhancement, though it’s often overlooked or discounted.
    Think of progressive enhancement in the same way you think of the cascade in CSS. It’s a layered approach, with the most basic stuff at the lowest layer and the fancy sprinkles on top.

  • http://autisticcuckoo.net/ AutisticCuckoo

    I once wrote an article for Accessites on this topic, which may be of interest to the readers here. It’s a bit more in-depth than Craigs summary.

    Graceful Degradation & Progressive Enhancement

  • http://fvsch.com Florent V.

    The difference between graceful degradation and progressive enhancement has always seemed artificial to me. Like it’s basically the same thing, the same set of techniques, and only the focus changes. Progressive enhancement is painted as half-full, while graceful degradation is sometimes described as half-empty.

    The example chosen in this article doesn’t tell much. What if I use a PNG-32 with a sensible bKGD chunk to avoid the ugly rendering in IE6? In some cases, it might look better in IE6 that the progressively enhanced PNG-8 (hum, that was a GIF in your example); is it still graceful degradation?

    Let’s take another example. Say i have a container for an article’s content. My design has a fluid width, but i want to avoid lines of text over approximately 80 characters. So i use max-width with a carefully chosen EM value to restrict the width of that container. What about IE6 support?
    1. I chose not to care about it. I then state it’s progressive enhancement because i have a working base in all browsers, and an additional optimization for users that support max-width.
    2. I chose not to care about it. I then state it’s graceful degradation because if a browser doesn’t support the optimal rendering, well at least it will support the degraded no-max-width rendering, which is acceptable.

    Which is more correct? If you opinion is that #1 is the most accurate definition, then what if i add a JavaScript code just for IE6, that takes care or reproducing the max-width functionality but only on page load (not taking into account window resizing). Surely that two-step development, with a base version that we take extra steps to make usable in non-supporting browsers, means it’s graceful degradation and not progressive enhancement anymore?

    This definition business is a bit of a mess. :)

    Additionally, some articles out there proclaim that progressive enhancement is better than graceful degradation. I would be interested on your stance on this.

    Carefully structuring a site with progressive enhancement in mind, there is no need to set up a secondary interface that requires us to maintain two side-by-side presentations of the same data.

    Then you considered the problems brothercake was referring to (assistive technology do support JavaScript), and have a solution that doesn’t imply explicitely offering users a non-scripted version? It would be nice to say what your solution is.

    By the way, if you apply the principles of progressive enhancement for Ajax-based functionality, then you do have code duplication: the classic HTML forms pages, and the JavaScript/Ajax code that alters part of your pages and does some of your website’s HTTP requests. You have to maintain two side-by-side interfaces, even if it’s only for one feature on one page of your website. You won’t escape that.

  • http://www.optimalworks.net/ Craig Buckler
  • FuzzFree.com

    Actually, they “should” be forced to change a working environment (just a browser…) – this is ONLY good for them for ONLY one reason (and the MOST important): SECURITY.

  • the.peregrine

    Then you considered the problems brothercake was referring to (assistive technology do support JavaScript), and have a solution that doesn’t imply explicitely offering users a non-scripted version? It would be nice to say what your solution is.

    You may be making this more complicated than necessary, Florent. The difference between progressive enhancement and graceful degradation is explained well in the article linked by AutisticCuckoo (I’ve referred hundreds of people to that article, as it’s one of the best I’ve ever seen on the subject).

    Javascript is an enhancement. I deliver everything necessary at the most basic level (HTML + CSS, with or without server-side scripting to handle such things as includes), then enhance the presentation where needed with javascript, Flash, or another technology appropriate to the purpose. I use the <noscript> tag to explain to users that their lack of script support is not denying them anything important, and that the experience is merely enhanced for everyone else.

    Designing like this may require a paradigm shift for some people. It would be difficult to impose progressive enhancement later on a site that was built otherwise. If you see yourself as an AJAX or Flash developer, determined to build everything that way, any discussion of progressive enhancement is probably a waste of your time. But if you’re committed to standards and accessibility, I believe progressive enhancement is THE way to make it all work for the largest possible audience.

    That’s what I believe and practice. I don’t say it’s what everyone else should do, but I think it has many advantages.

  • http://www.optimalworks.net/ Craig Buckler

    @FuzzFree.com
    If security is the most important issue, why not install Lynx? No scripting, no plugins, no big downloads, no time-wasting, no problems.

    I’m not convinced the security argument will sway many corporations. XP and IE6 have received 8 years of security updates.

  • Stevie D

    The difference between graceful degradation and progressive enhancement has always seemed artificial to me.

    There is quite a clear distinction, and it is important.

    With graceful degradation, you start with an all-signing all-dancing high-falutin’ page that probably relies on a lot of scripting and styling. And even if all your scripts are neatly stored in external files, they will be called directly from the HTML.

    The result of this is that for the page to degrade gracefully, you have to specify the fallback mechanisms for every event that might fail, and rely on user agents correctly picking up those fallback mechanisms – eg, browsers with some Javascript functions disabled will not read <noscript> elements, so might miss vital instructions.

    With progressive enhancement, you start with a fully functioning pure HTML page, and then use unobtrusive scripting to improve the user experience and add non-essential additional functionality. This ensures that if any of those functions are not available, there will always be a working fallback.

  • http://fvsch.com Florent V.

    You may be making this more complicated than necessary, Florent. The difference between progressive enhancement and graceful degradation is explained well in the article linked by AutisticCuckoo (I’ve referred hundreds of people to that article, as it’s one of the best I’ve ever seen on the subject).

    I had read that article and a few others back in the days, but apparently i had missed a few things. Actually i was using the phrases “progressive enhancement” and “graceful degradation” when referring to user agent behavior rather than the website building process. It obviously refers to the building process, hence the confusion. I’ll try to use the definitions from that article in the future. (Just for the record: i do progressive enhancement most of the time.)

    Now that the definitions issue is cleared (thanks @Stevie D too), i still challenge you idea that explicitly offering a non-scripted access to users is a no-go. It’s great to make sure that your website is accessible without JavaScript, but what about users who do have JS enabled but won’t be able to use your website because the DOM as modified by your JavaScript is not accessible?

    1. You decide that JavaScript is inherently a non-accessible technology, and users who can’t use JavaScript effectively should just disable it for every website out there. You do progressive enhancement and that’s it.

    2. You recognize that your JavaScript code is not accessible, and don’t want to go the ARIA road; some users may need JavaScript on some sites but can’t use JavaScript on yours, but it’s their responsability to switch JavaScript on and off for different websites they visit, or use some kind of filter.

    3. You recognize that your JavaScript code is not accessible, and don’t want to go the ARIA road; but you want to help users accessing your website sans-JavaScript, so you provide a server-side switch to help them. (That’s what brothercake suggests.)

    4. You boost your JavaScript code’s accessible using ARIA. You do that on top of progressive enhancement, so that you cover as many possibilities as possible.

    5. You decide that JavaScript is now an accessible technology (if done right). You build a website that relies a lot on JavaScript (let’s say it’s a rather complex web app), and use ARIA extensively to make it accessible. Your website depends on JavaScript all right, but it may make sense for your project.

    None of these amount to “set up a secondary interface that requires us to maintain two side-by-side presentations of the same data”. #1 is a classic answer, but has its flaws and kinda relies on a misconception (only non-disabled users have JavaScript enabled). #2 is an interesting take, though it’s rather unrealistic. #3 is an interesting workaround for the inaccessible JS issue, but only if done right. #4 is “ideal” but costly and may not be possible for some applications. #5 is a new answer, and a daring one that’s bound to outrage a few web developers.

    I’m quite found of #5. #3 is interesting too, though i’d be curious what a good way to offer the switch would be.

  • the.peregrine

    OK, Florent, let me back up a bit and explain where I’m coming from.

    1) I work daily with people who have various disabilities. Their abilities, along with the adaptive software they use or don’t use, shape the way I think about all of this.

    2) I work for a state government agency in the U.S., and for that reason I am required to practice due diligence in making everything as accessible as possible.

    So … it’s not that I decide what is accessible or inaccessible, thumbs up or thumbs down; it’s what this user experience demonstrates to me that really matters. When we get right down to it, I guess maybe we could rate accessibility on some kind of a scale. But people are different, and our abilities are different, and what is accessible to some is not accessible to all. It isn’t for me to judge what is accessible and what isn’t, but my job is to make things as accessible as possible.

    There is no magic measuring stick or validator that will tell us when we’ve reached the optimum range of accessibility. Even when we try very hard, our best efforts may be inaccessible to someone.

    I live in a state that has a lot of rural areas with no broadband access, although I enjoy broadband access myself. If I load up a lot of javascript on people, they feel it right away in their download time because javascript is a client-side technology that has to be first downloaded and then executed. Most developers overlook that because we have the fast gear and the fast pipeline, but not everyone puts a high priority on geek gear and it’s arrogant and wrong for us to place that expectation on our customers. Some people have a hard time feeding their families, and I design for them, too. I measure my download times in microseconds and seconds, they measure theirs sometimes in minutes.

    Client-side technologies will be disabled by all kinds of people, including me. Craig mentioned Lynx in his reply above, and I use Lynx sometimes myself just to retrieve data VERY quickly (it ignores images and scripts, so it’s blindingly fast on a good connection). On the other hand, server-side technologies are invisible to user agents because they do their work before it gets sent down the pipe, so they can speed up the delivery where client-side technologies will always slow it down.

    Make everything as simple as possible, but not simpler. … Albert Einstein

    Our basic purpose here is to communicate, so we have to constantly ask ourselves how to simplify our message and deliver it as succinctly as possible (yeah, right … what have I written here? 200 words?;). We can pretty it up on another level if end users allow it, but it’s wrong for us to demand that they do. [This is just my opinion, to which the response from interface designers is frequently something brilliant like "Oh yeah? Well ... you SUCK!"]

    Progressive enhancement in web development is a little like building a car. It wouldn’t be a car without wheels, engine, chassis, steering and seats, so you build those first (HTML). You might like to have a cool paint job and tinted windows and leather interior, too (add some CSS styling). Extra horsepower might be nice (server-side scripting, database connectivity). Then some gangsta wheels and a sweet sound system, maybe even some neon lights on the undercarriage (scripts and widgets and web apps). Theoretically, according to the theory of progressive enhancement, you can take away anything beginning at the end of the list and everything else should still get you where you’re going.

    So in a way, what we’re talking about here is also a kind of graceful degradation. We used to talk about graceful degradation only in terms of content rendering in older browsers. I’m talking about it now in terms of content rendering in any browser, giving the end user full choice of which enhancements serve his/her needs and which to disregard.

    Sorry for the long answer! Seems important to me, so I sometimes get carried away with it.</p.