Designing with Progressive Enhancement Building the Web that Works for Everyone
Designing with Progressive Enhancement, from Boston-based agency Filament Group is by far the densest, most “engineery” book I’ve set out to review on this site. This is not one of those “absorb it in an afternoon” coding books.
The book is divided into two major sections. Section I, “The Test-Driven Progressive Enhancement Approach” covers the philosophy and basic principles of Filament’s web development methodology. Section II, “Progressive Enhancement in Action”, applies said methodology to real-world design and functionality challenges.
Section I: The Test-Driven Progressive Enhancement Approach
Introduced in Chapters One and Two, Filament’s Progressive Enhancement approach is, as I understand it:
Analyze the component you want to build (say, a modal login window) with an “x-ray perspective”, deciding what basic, semantic html should be used as a foundation.
Having built this foundational “basic experience”, test the browsing environment for the capabilities required to deliver an “enhanced experience”.
While many web development books conclude with case studies, the bulk of Chapter 2 dives right in to four real-world examples, showing how the x-ray perspective might be applied. These examples give a whirlwind tour of some of the visual, functional, and accessibility considerations involved in building application-like interfaces on the web, and provide the raison d’etre for the rest of the book.
Chapters 3 and 4 cover territory that should be familiar to any competent, web-standards-based developer, such as using html to give your content hierarchical structure, and choosing semantic class and id names. One concept that was new to me was the addition of WAI-ARIA landmark and widget roles for accessibility, which the authors revisit throughout the book.
Section II: Progressive Enhancement in Action
The first section of this book left me with a couple of overarching impressions:
- “While this all sounds like a very robust and responsible approach, it also seems like a major chore, and a good way to make building websites a lot less fun.”
- Following on that: “Thank goodness I work on small, mostly informational sites. While I can’t say the pay is stellar, at least I don’t have to deal with building a slider widget that is accessible in the gamut of browsing environments including screen readers” (first introduced on page 33).
However, Section II largely alleviated these feelings by providing a wealth of techniques and ready-to-use tools for building common interface components, such as the aforementioned accessible slider (Chapter 16). The authors clearly spent a lot of time developing and testing the twelve solutions described, and reward the reader not only with the insights gained, but also downloadable, ready-to-use scripts.
They provide some elegant and robust (though I’m taking their word on that part) solutions, such as stacking a label element over radio buttons and checkboxes for fancier styling (page 299), or using opacity to hide the native file input and display a custom one (page 400).
Taking a cue from Paul Boag, I would question the “return on investment” for a couple of the solutions. For example, starting with
<button /> elements, simply to allow more complex styling seems like a lot of effort for small payoff. Granted, this may simply be a convenient example to demonstrate a technique (and, it should be noted, the authors have done all the work, and provided the necessary script for download), but in general it seems worth stepping back and questioning whether the “enhancements” you’re making are worth the time and expense.
While even someone working on relatively simple websites will benefit from reading this book, Designing with Progressive Enhancement is most useful for those developing application-like sites with rich user interaction.
Reading this book and the two books on Microformats I plan to review have made me question: who should ultimately be responsible for making website functionality and information more accessible? WAI-ARIA roles and Microformats are actually very similar: they are essentially layers of metadata—WAI-ARIA to help people with disabilities use a site, and Microformats to help make data interoperable and exchangeable across machines. Is it wise for the onus to be on millions and millions of disparate developers, designers, and content producers to provide this extra richness? To me it seems inefficient at best, and hopeless at worst.
More on this to come.
No comments yet…Be the first!
Comments are closed for this article.