Graceful Degradation & Progressive Enhancement

Posted February 6th, 2007 by Tommy Olsson

Form Validation

Form validation is a common use for JavaScript, but one can obviously not rely on it. If we did, someone who has disabled client-side scripting could submit invalid data, and a nefarious script could abuse our form for who-knows-what.

Validating form data is something which must always take place on the server side, but for efficiency reason we may wish to use client-side validation in addition to that. It will benefit users by giving quicker feedback and it will benefit us because it reduces the number of requests to our servers.

Using the methods outlined above, we can add our JavaScript validation unobtrusively and with object detection. A modern browser with JavaScript enabled will enhance the validation process, while we still retain our back-end validation for the script-challenged minority (and to preserve our own mental health).

Ajax

AJAX became an important buzzword last year. Everyone must use it, whether they really needed it or not. Sometimes I get the feeling that it is an answer in search of a problem, but there is no denying that it is a useful technique for some common situations.

Consider a form with two or more select elements (drop-down lists or list boxes) where each select is dependent on the previous one. Typical examples are drill-down choices for type/subtype or country/state. Depending on what you select in the first list, the content of the second list should change. How can we make this work as well as possible for all users?

We will once again begin with the basics. Do not think about client-side scripting at this stage; think only about HTML support:

 Example Eight (in HTML)
 <form action="products.php" method="post">
  <fieldset>
   <legend>Product Type</legend>

    <label for="type">Type</label>
     <select name="type" id=”type”>
      <option value="none" selected>- select a type -</option>
      <option value="widgets">Widgets</option>
      <option value="gadgets">Gadgets</option>
     </select>
     <input type="submit" name="chooseType" value="Select">

     <br>
     <label for="subtype">Subtype</label>
      <select name="subtype" id="subtype" disabled>
       <option></option>
      </select>

     <br>
     <input type="submit" name="show" value="Show Products" disabled>
   </fieldset>
  </form>

Our primary list (Type) is populated with our product types: widgets and gadgets. The secondary list (Subtype) is empty and disabled, and the main submit button (Show Products) is disabled. A user needs to choose a product type and then activate the other submit button (”Select”). The form is submitted to our server-side script (products.php), which will then redisplay the form with the subtype list populated with the subtypes of the selected type (or a friendly error message if no type was specified).

The user can then select a subtype and submit the form using the “Show Products” button (which is not disabled this time). If she changes her mind and wants to select another type, she will have to activate the “Select” button again to load the correct subtypes.

This is not the most user friendly form in the world, and it needs some rather tedious (but straightforward) server-side scripting, but it works in virtually all browsers. Even Lynx handles forms like this one.

But we would like to make it faster and easier to use. It would be nice to populate the secondary list as soon as the selection changes in the primary list. This requires JavaScript. More often than not the choices of types and subtypes are dynamic and need to be retrieved from a database rather than being hard-coded, which makes this a likely candidate for an AJAX solution.

We would use unobtrusive JavaScript to detect support for the necessary features (mainly XMLHttpRequest). If supported, we would add an event handler for the primary list using addEventListener() or attachEvent(), depending on the user’s browser. Then we would remove the “Select” button using the removeChild() DOM function, because it is no longer necessary and would only be confusing.

The added event listener would open an asynchronous connection to our server and post an HTTP request specifying the selected type. The server script would query the database and return an XML reply containing the available subtypes, which we would then parse and use to populate the subtype list (with DOM functions). Then we could enable the subtype list and the main submit button.

A JavaScript-enabled browser that lacks support for AJAX could submit the form automatically to a server-side script that would redisplay the form with a populated secondary list, much like the non-scripted version but without requiring the user to activate an extra button.

This is progressive enhancement: it works for everyone, but users with modern browsers will see a more usable version. We are, in a way, rewarding them for choosing to use a good browser, without being rude to Lynx users or employees of companies with paranoid IT departments. We don’t even have to trust the unreliable noscript element, and since we would use object detection rather than browser sniffing we don’t have to keep updating the JavaScript for every new browser version.

Continuation of Article Pages: 1 2 3 4


21 Responses to: “Graceful Degradation & Progressive Enhancement”

  1. Graceful Degradation & Progressive Enhancement « B-link List responds:
    Posted: February 6th, 2007 at 11:32 pm

    […] read more | digg story […]

  2. Mike Pearce responds:
    Posted: February 7th, 2007 at 4:21 am

    Great article - I’ve always used progressive enhancement as it just felt ‘right’ - although I never knew what it was called!

    Thanks!

  3. Joe Dolson responds:
    Posted: February 7th, 2007 at 6:03 pm

    Nice article, Tommy! Really appreciated the JavaScript code example - it was perfectly concise and understandable, even to my under-educated scripting brain. :)

  4. Mike Cherim responds:
    Posted: February 7th, 2007 at 8:36 pm

    I have to chime in with Joe, Tommy. Really terrific article.

  5. Mat Jakob responds:
    Posted: February 8th, 2007 at 2:33 am

    I’d love to read the article, but I have a problem to do so. I like to print interessting articles and read them on the way home from work (train) to fil out the dead time. Problem is, the paging on this and some other sites I came across lately makes it hard to print articles. I’ve looked hard to find the “print the entire article” button… no success. Shouldn’t the article be available for people who cannot or don’t want to read it on screen (especially on this site)? Am I missing something here?

  6. Robert Wellock responds:
    Posted: February 8th, 2007 at 6:10 am

    I like your “Besides…” part youngman.

  7. Mike Cherim responds:
    Posted: February 8th, 2007 at 8:54 am

    @Mat: We do have a print style sheet that should make it doable. What happens if you go to each page and print it with your browser? Do you get that page printed?

  8. Mike Cherim responds:
    Posted: February 8th, 2007 at 9:15 am

    Never mind, I see the problem: the comments are printed with each page. As a service to you and our other readers, this should help. Get Graceful Degradation & Progressive Enhancement as text. Please let me know if that works for you, as in prints the characters properly and wraps the lines as it should.

    Update: I also added a block to the comments in the print style sheet so maybe that’ll give you two options.

  9. Shane Holland responds:
    Posted: February 8th, 2007 at 4:31 pm

    Very nice article, Tommy! Nice explanations, and a great overview. Good work.

  10. Mat Jakob responds:
    Posted: February 8th, 2007 at 6:13 pm

    The text version worked like a charm. Thank you! I could have printed the 4 pages seperately. Next to beeing tedious the comments would have been in the way. So thanks for removing them for print. For me and anybody else who likes to print long article it’s easiest to if i’m able to print the whole article at once. — END off topic comment –

    @Tommy: Very good and clear explanation of the two concepts. I’ve read about and used them before but had not yet found such a clear explanation. And I really liked the example with the dependent selects. Great article, thanks!

  11. Patrick responds:
    Posted: February 13th, 2007 at 1:21 pm

    Removing the “Select” button in the double list AJAX example may not be the best idea. Blind users (or others who are required to navigate by keyboard only) hate lists that immediately accept a change when a new item is selected, because scrolling by keyboard changes the selected item. Causing the first list to immediately repopulate the second list when scrolling through it is okay, but the second list should not perform an action on selecting an item. The action should only be triggered by pressing the “Select” button, otherwise it is impossible to just look through the list using the arrow keys.

  12. AnySurfer blogt » Graceful Degradation versus Progressive Enhancement responds:
    Posted: February 14th, 2007 at 11:30 am

    […] Graceful Degradation versus Progressive Enhancement Geschreven door Roel Van Gils om 17u19 Twee termen waar je als web developer wel eens mee om de oren wordt geslagen. Maar wanneer spreek je nu eigenlijk over graceful degradation, en wat is dan progressive enhancement? Tommy Olsson legt uit dat het mes aan twee kanten snijdt. Weer wat bijgeleerd. […]

  13. SitePoint Blogs » Handling JavaScript-disabled Browsers responds:
    Posted: February 22nd, 2007 at 9:49 pm

    […] If you’d like to read more about graceful degradation and progressive enhancement, I highly recommend SitePoint regular Tommy Olsson’s article on the subject at Accessites.org. Tags: JavaScript, accessibility, progressive enhancement […]

  14. Domain Name Diary » Handling JavaScript-disabled Browsers responds:
    Posted: February 22nd, 2007 at 10:18 pm

    […] If you’d like to read more about graceful degradation and progressive enhancement, I highly recommend SitePoint regular Tommy Olsson’s article on the subject at Accessites.org. […]

  15. developercast.com » Blog Archive » Handling JavaScript-disabled Browsers responds:
    Posted: February 24th, 2007 at 11:44 am

    […] If you’d like to read more about graceful degradation and progressive enhancement, I highly recommend SitePoint regular Tommy Olsson’s article on the subject at Accessites.org. […]

  16. tigerkin responds:
    Posted: February 25th, 2007 at 4:37 am

    Thank you very much!
    Now, I use both graceful degradation and progressive enhancement to our web applications. I prefer progressive enhancement to graceful degradation. Because JavaScript can perfectly control every element in the document with DOM, you can do everything what you want to do. So I think that standard JavaScript and DOM is the foundation of progressive enhancement technique.

  17. Graceful degradation and progressive enhancement(1) | San Jose Web Design | Silicon Valley website Development | Campbell SEO services : News Archive responds:
    Posted: February 27th, 2007 at 9:14 pm

    […] Posted February 6th, 2007 by Tommy Olsson […]

  18. Spider Trax » Dutch Government Promotes Web Accessibility responds:
    Posted: February 28th, 2007 at 7:58 am

    […] Progressive enhancement […]

  19. ThePickards » Blog Archive » WCAG 2.0, Validity and The Holy Trinity responds:
    Posted: March 23rd, 2007 at 12:33 pm

    […] This service also had a non-Flash method for reporting a repair which wasn’t as good. That’s what we call Graceful Degradation or Progressive Enhancement. And that’s fine. Great site, great piece of accessible Flash, with a non-Flash fallback. Perfect. […]

Sorry. Comments are closed.




Note: This is the end of the usable page. The image(s) below are preloaded for performance only.