Accessites.org
Graceful Degradation & Progressive Enhancement

Not-So-Graceful Degradation

Unfortunately the concept of graceful degradation sometimes deteriorates way past the point where the adjective “graceful” can reasonably be applied. The worst case is code like this:

 Example Two
 <script type="text/javascript" src="/menu.js"></script>
  <noscript>
    <p>Please upgrade to a browser that supports JavaScript.</p>
  </noscript>

This is unacceptable for any serious web site, but may be forgiven on a small amateur site whose target audience is friends and family.

We, as web designers or developers, have no right to tell our visitors which browser they “should” use; nor do we have the right to tell anyone to “enable JavaScript.” We don’t know why this visitor uses Lynx or why that visitor has disabled client-side scripting. They may not even have the option of “upgrading” or “enabling JavaScript” because of bandwidth, hardware or budget constraints; IT department policy; or because they are not even using their own computer.

Graceful degradation is far better than having a site that is completely inaccessible to some users, but it is not the best approach. As with the visual design approach, it is often difficult to begin with all the features and then remove them one by one, without everything falling apart.

Progressive Enhancement

Progressive enhancement became known — at least under that name — in 2003, when Steve Champeon began using it on Webmonkey and during the SXSW conference. It starts at the opposite end from graceful degradation: begin with the basic version, then add enhancements for those who can handle them. Again, comparing it to the design approaches: this is the same basic thought as in structural design. That starts with the markup and adds styling on top of that, which is progressive enhancement all by itself.

The most common occurrence of progressive enhancement is probably the external CSS style sheet. It is ignored by non-CSS browsers — which thus get only the plain markup and render it according to their own built-in style sheets — but it is applied by modern graphical browsers, thus enhancing both the aesthetics and the usability for mainstream and advanced users.

Other examples of progressive enhancement are the various image replacement techniques, the Flash satay method and (sometimes) AJAX.

Progressive enhancement when it comes to JavaScript is becoming more common these days. The key to this is known as unobtrusive JavaScript. An unobtrusive script is silently ignored by user agents that do not support it, but is applied by more capable devices. Just like an external style sheet.

Let us revisit the navigation menu we examined as an example of graceful degradation. How would that be done using progressive enhancement?

We would begin by creating our markup, aiming for the lowest common denominator: HTML. A navigation menu is, semantically, a list of links. The order of those links does not affect the meaning of the list as a whole; thus it is an unordered list.

 Example Three
   <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/products/">Products</a></li>
    <li><a href="/services/">Services</a></li>
   </ul>

This will work in everything from Lynx and Mosaic 1.0 to the latest versions of Opera, Firefox and Safari. Googlebot and its arachnoid cousins will also love it.

The next step is to add enhancements for the vast majority of users whose browsers support CSS. We add rules in an external CSS file to style the menu. After adding a link element with a reference to the external style sheet, it looks a lot better to most visitors, but it is in no way detrimental to those Lynx users or to the Googlebot. (OK, they’ll have to download a few more bytes, but it will be negligible even on a slow dial-up connection or a GSM mobile phone.)

But we can enhance this further by adding drop-down or fly-out or expanding sub-menus to the main items, using unobtrusive JavaScript. To reduce the amount of script code, we begin by assigning ids to the list items:

 Example Four
    <li id="products"><a href="/products/">Products</a></li>
    <li id="services"><a href="/services/">Services</a></li>

Then we create a separate JavaScript file with a couple of functions:

 Example Five
 function addProducts()
  {
   // Find the li element to which we will add a sub-menu
   var parent = document.getElementById("products");

   // Make sure it exists (fail silently)
   if (parent) {

   // Create a nested unordered list
   var ul = parent.appendChild(document.createElement("UL"));

   // Add the list items and links
   var items = [ ["Blue Widgets", "blue"],
                   ["Red Widgets",  "red"] ];

   for (var i = 0; i < items.length; ++i) {
        var li = ul.appendChild(document.createElement("LI"));
        var a  = li.appendChild(document.createElement("A"));

          a.href = "/products/" + items[i][1];
          a.appendChild(document.createTextNode(items[i][0]));
       }
    }
 }

The addServices() function would look very similar. Then we need to be sure that the browser can handle those DOM functions:

 Example Six
 function createSubMenus()
  {
   // Make sure that the DOM functions we will use are supported
    // (fail silently)
     if (typeof document.getElementById != "undefined"
        && typeof document.createElement != "undefined"
        && typeof document.createTextNode != "undefined")
       {
         addProducts();
         addServices();
       }
  }

This function makes sure that the main DOM functions used by addProducts() and addServices() are supported by the browser. If not, the function does nothing; it causes no harm and there will be no JavaScript error message or warning icon. This approach is called object detection and is infinitely better than the old-school browser sniffing scripts that stopped working as soon as a new browser (or a new version of an existing browser) was released.

Finally, to get the browser to call those functions as soon as the page has loaded.

 Example Seven
  if (window.addEventListener) {
     window.addEventListener("load", createSubMenus, false);
  } else if (window.attachEvent) {
     window.attachEvent("onload", createSubMenus);
  } else {
     window.onload = createSubMenus;
  }

Note that this piece of code is not enclosed in a function. It will add an event listener for the window’s “load” event, calling our menu-creating function immediately after the HTML document has finished loading. (We need to wait for that, so that the id attributes are available.)

Modern browsers will use the addEventListener() function specified in the DOM Level 2 (Events) specification, while Internet Explorer will use its proprietary attachEvent() function.

The last catch-all is not perfect: it will replace any existing onload handler created by a previous script. That is hardly unobtrusive. In real life we would need a slightly more complicated solution for this case, but I don’t want to make the examples unnecessarily complicated.

We will add a script element in the HEAD section of our document to load the external JavaScript file:

<script type="text/javascript" src="/menu.js"></script>

As a final step we would add CSS for those sub-menus and JavaScript event listeners to display or hide them, making sure to handle both mouse and keyboard activation, of course.

Continuation of Article Pages: 1 2 3 4

Filed under Our Articles —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati | Help |

These posts may be related:

Everything is a Progressive Enhancement »

Confirming a Web Site’s Accessibility »

Lotus from the Mud »