Posted February 6th, 2007 by Tommy Olsson

Graceful degradation and progressive enhancement are two sides of the same coin. Both are — in this context — applied to make a web site accessible to any user agent, while providing improved aesthetics and/or usability for more capable browsers. The difference between the two is where you begin your approach.

Some time ago I wrote an article here about two very different approaches to web design: Visual Vs. Structural. The concepts of graceful degradation and progressive enhancement relate closely to those two approaches.

Graceful Degradation

Graceful degradation is the older of the two concepts. The term is also used in fields other than web design, such as fault tolerant mechanical or electrical systems.

The premise for graceful degradation is to first build for the latest and greatest, then add handlers for less capable devices. In other words, focus on the majority before catering to those outside the mainstream. This is quite similar to the visual approach of web design, where the first priority is to make it look good to most visitors.

A familiar example of graceful degradation is the alt attribute for images. When used properly it provides a text equivalent that conveys the same information as the image to users who cannot perceive the image itself. The text equivalent is most likely not as aesthetically pleasing, and an image can say more than a thousand words, so the user experience is slightly degraded.

Using layout tables may be seen as one form of graceful degradation: if the CSS styling cannot be applied — e.g., in really old browsers — at least the basic page layout is retained. But it doesn’t work very well for text browsers like Lynx and some mobile phone browsers, which do not support tables.

Another common occurrence in sites built from the graceful degradation point of view is the noscript element. You provide some feature based on JavaScript and add a more basic version for user agents that do not support JavaScript or have client-side scripting disabled. One example could be the ubiquitous drop-down or fly-out menu:

The JavaScript function may create a menu where “Products” and “Services” have sub-menus that drop down, fly out or expand when the user’s mouse pointer hovers over the main items. The non-JavaScript alternative provides immediate access only to the main items, while the sub-menus are (presumably) included in similar noscript elements on the respective interior pages.

This approach is designed for mainstream users — those with a graphical browser that supports JavaScript — but it degrades gracefully so that it works in even the humblest of text browsers. It also adds the benefit of proper HTML anchor links to non-JavaScript user agents like search engine spiders, thus negating the critical SEO disadvantage of JavaScript menus.

There is one problem with noscript, though. I may use a browser that supports JavaScript and has it enabled, but there could be a company firewall that strips incoming JavaScript for security reasons. In this case the noscript element will not be rendered (because my browser supports scripting) but the JavaScript code that should create the menu won’t be applied either, because it gets stuck behind the firewall.