Designing with Progressive Enhancement
Building the Web that Works for Everyone
DESIGNING WITH PROGRESSIVE ENHANCEMENT:
BUILDING THE WEB THAT WORKS FOR EVERYONE
Todd Parker, Patty Toland, Scott Jehl, Maggie Costello Wachs
NEW RIDERS
1249 Eighth Street
Berkeley, CA 94710
510/524-2178
510/524-2221 (fax)
Find us on the Web at www.newriders.com
To report errors, please send a note to [email protected]
New Riders is an imprint of Peachpit, a division of Pearson Education
Copyright © 2010 by Filament Group, Inc.
The Filament Group, Inc. is Todd Parker, Patty Toland, Scott Jehl, and Maggie Costello Wachs.
Acquisitions Editor: Wendy Sharp
Project Editor: Wendy G. Katz
Technical Editor: James Craig
Production Editor: Myrna Vladic
Composition: David Van Ness
Indexer: Jack Lewis
Interior Design: Mimi Heft
Cover Design: Aren Howell
Notice of Rights
All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on getting permission for reprints and excerpts, contact [email protected].
Notice of Liability
The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the preparation of the book, neither the authors nor Peachpit shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it.
Trademarks
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Peachpit was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book.
ISBN-13: 978-0-321-65888-3
ISBN–10: 0-321-65888-4
9 8 7 6 5 4 3 2 1
Printed and bound in the United States of America
Contents
SECTION I THE TEST-DRIVEN PROGRESSIVE ENHANCEMENT APPROACH
Planning for progressive enhancement: the x-ray perspective
From x-ray to action: the building blocks of progressive enhancement development
chapter 2 progressive enhancement in action: the x-ray perspective
An overview of the x-ray perspective
Defining content hierarchy and mapping components to HTML
Building foundation markup and minimal, safe styles
Applying markup, style, and script enhancements
Case 1: Planning structure and organization in a news website
Evaluating content organization and naming
Leveraging native HTML hierarchy features for content organization
Accommodating layered and animated content
Supporting dynamic filtering and sorting
Case 2: Workflows, validation, and data submission in a checkout form
Breaking down the checkout form design
Marking up the form to ensure accessibility
Applying constraints and validation
Assembling the basic and enhanced experiences
Case 3: Interactive data visualization in a budget calculator
Choosing basic markup for the budget line components
Creating accessible sliders from the foundation markup
Case 4: Supporting full-featured application capabilities in the browser—the Photo Manager
Marking up global navigation elements
Supporting complex album and multi-photo interactions
Creating custom forms and overlays
Building in Back-button support
Checklist for implementing the x-ray in action
chapter 3 writing meaningful markup
Elements for meaningfully marking up text
Embedding external page content
Marking up interactive content
Know when to use block-level vs. inline elements
Identify elements with IDs and classes
Identify main page sections with WAI-ARIA landmark roles
Accessibility guidelines and legal standards
Web Content Accessibility Guidelines (WCAG)
chapter 4 applying styles effectively
Maintaining styles in external style sheets
Linking to external style sheets
Using meaningful naming conventions
Styling the basic and enhanced experiences
Safe styles for the basic experience
Styling the enhanced experience
Dealing with bugs and browser inconsistencies
chapter 5 scripting enhancements and interactivity
How to properly reference JavaScript
Referencing external JavaScript
Understanding JavaScript’s place in the basic experience
Best practices for scripting enhancements
Running scripts when content is ready
Building enhanced markup with JavaScript
Preserving and enhancing usability and accessibility
Maintaining state and preserving the Back button
chapter 6 testing browser capabilities
EnhanceJS: a capabilities testing framework
The mechanics of EnhanceJS: how the tests work
Applying enhancements with EnhanceJS
Loading additional style sheets
Customizing the experience toggle link
Forcing EnhanceJS to pass or fail
Extending the EnhanceJS test suite
Modifying the test suite with EnhanceJS options
Creating new or multiple instances of EnhanceJS
Enabling the capabilities test alert for debugging
Optimizing EnhanceJS on the server
SECTION II PROGRESSIVE ENHANCEMENT IN ACTION
chapter 7 building widgets with progressive enhancement
Navigating the widget chapters
Creating accessible collapsible content
Collapsible enhancement script
Bookmarking and history (Back button) tracking
Referencing external tab content
Displaying tabs as an accordion
Creating a tooltip from title content
Creating a tooltip from an anchor link
Creating a tooltip from an external source
chapter 12 charts with html5 canvas
Using canvas to visualize data
Taking canvas charts further: the visualize.js plugin
chapter 13 dialogs and overlays
Creating buttons with complex visual formatting
Enhanced input-to-button script
Using the input-to-button script
chapter 15 checkboxes, radio buttons, and star rating
Taking custom inputs further: a star rating widget
Scripting the star rating widget
Using the custom input and star rating scripts
Creating an accessible custom select
Taking the custom select further: advanced option styling
Using the custom select script
Taking the list builder further: multi-select, sorting, auto-complete, and contextual menus
Creating the custom file input
Using the custom file input script
Acknowledgments
First, we want to thank Peachpit/New Riders for giving us the opportunity and the incentive to write this book. We’ve been considering accessibility and using test-driven progressive enhancement in our projects and on our site for years, but Peachpit’s encouragement prompted us to take the plunge and articulate the principles and techniques we’ve pieced together into a cohesive whole for this important topic. If only for our own benefit, the exercise has been incredible. We deeply appreciate the invaluable input we’ve received along the way.
Specifically, a huge thanks to our two Wendys at Peachpit/New Riders: Wendy Sharp, who found our online lab and reached out to invite us to write this book, and provided invaluable insights and expertise about shaping our ideas for this medium; and Wendy Katz, whose careful and thoughtful editing, and infinite humor, wit, and patience, were essential to getting us through to the end. Thanks also to Glenn Bisignani for his marketing insights and support; and Aren Howell, Mimi Heft, and David Van Ness for their beautiful designs.
We owe our technical editor, James Craig, an enormous debt. His thoughtful advice and invaluable expertise in accessibility and ARIA have measurably improved the quality of our recommendations. Where we get accessibility recommendations right, it is very frequently thanks to his contributions. (And, importantly, if we get it wrong, that responsibility is our own.)
Thanks to John Resig and everyone on the jQuery and jQuery UI teams for their support and the incredible JavaScript library that we so enjoy working with—throughout this book and in our everyday work. And very special thanks to Brandon Aaron, for contributing to, and significantly improving, the performance of our EnhanceJS framework.
We want to acknowledge our valued clients and colleagues, who have encouraged us think about these important ideas in our work for them and provided real-world challenges that inspired many of the solutions in these pages. We thank Steve Krug for his advice and encouragement, and Derek Jones for his help with book production.
And we would also like to recognize many organizations that have been incredibly generous in offering a public forum for us to share, discuss, and refine many of ideas and techniques that went into this book: A List Apart Magazine, Delve UI Conferences, MIT WebPub, the Markup & Style Society, jQuery, Ajaxian, and Smashing Magazine.
Our work is built upon a foundation of ideas, techniques, and code that countless generous and brilliant people have shared publicly, and taught us personally, including: Tony Aslett, Doug Bowman, Andy Budd, Corey Byrnes, Dan Cederholm, Tantek Çelik, Steve Champeon, Andy Clarke, Jeff Croft, Derek Featherstone, Seth Ferreira, Nick Finck, Becky Gibson, Brandon Goldsworthy, Scott González, Marc Grabanski, Aaron Gustafson, Chris Heilmann, Dorothy Hesson, Molly Holzschlag, Shaun Inman, Paul Irish, Yehuda Katz, Jeremy Keith, Peter-Paul Koch, Bruce Lawson, Ethan Marcotte, Michael McGrady, Eric Meyer, Cameron Moll, Jon Reil, Richard Rutter, Travis Schmeisser, Dave Shea, Chris Smith, Jonathan Snook, Krista Stevens, Nicole Sullivan, Karl Swedberg, Randy Taylor, Dan Webb, Richard Worth, Jörn Zaefferer, Jeffrey Zeldman, and countless others.
Many of the techniques in this book were forged and refined with the help of the many talented and thoughtful individuals who read and comment on our lab blog; we greatly appreciate your encouragement, technical expertise, and criticism. And more importantly, we hope you will continue to embrace these ideas and contribute to both the commentary and the code that comprises our demos and downloadable plugins. (Please feel free to go to www.filamentgroup.com/dwpe to join the discussion.)
* * *
Personal acknowledgements
We all thank Christine Fichera for generous use of her photos throughout the book; and Todd thanks Christine and Nathan especially for letting this book intrude on bath and story time.
Patty thanks Judy Kohn and Jeff Cruikshank for being such great mentors and role models, and all the Tolands for their infinite patience and support even when they still don’t understand exactly what she does for a living.
Scott thanks his wife Stephanie and all his family and friends for their patience and encouragement while writing this book, and his parents for their uncompromised support and encouragement from day one.
Maggie thanks her husband Michael, family, and friends for their endless support, encouragement, and good humor; special thanks to her mom, Barbara Thompson, for a lifetime of inspiration, and to those who acted as sounding boards for many of the ideas expressed in this book.
Introduction: The Case for Designing with Progressive Enhancement
In many ways, right now is the best possible time to be a web designer.
New sites and applications emerge at an astounding rate and transform the way we work, communicate, and live. We manage our businesses, build our relationships, voice our opinions, educate ourselves about world affairs, and find a whole range of entertainment online. Advances in web standards are making the web easier, faster, and more dynamic and powerful all the time. And “online” has been liberated from the “line” itself—an explosion of web-enabled mobile phones and compact netbooks keeps us connected virtually everywhere.
But this bounty of Internet riches has a downside: while advanced interactions tend to work beautifully on the newest browsers that support advanced CSS and JavaScript, there’s a whole universe of web-enabled devices—from the newest Kindle or Wii gaming system to a wide range of older computers and mobile phones—that have limited or no support for these features, and can be left with a broken and unusable experience. And even with a modern browser, sites can exclude blind or vision-impaired users if web developers don’t take care to support keyboard interaction and layer in specific accessibility features required by screen-reader software and other assistive devices.
As web designers and developers, we are always balancing three somewhat conflicting objectives. We want to embrace all the exciting new technologies available to deliver compelling, interactive experiences. But at the same time, we’re deeply committed to ensuring that our sites are universally accessible, intuitive, and usable for everyone. And from a development perspective, it’s equally important to write the cleanest and most maintainable code possible. It’s been our quest to find a development approach that will satisfy all three objectives in an elegant way that will work on real-world projects.
Happily, we think we have found a way. Designing with Progressive Enhancement is a practical guide to web design and development that focuses specifically on how to create sites that deliver the highly interactive experiences that JavaScript, advanced CSS, and Ajax afford, and at the same time ensure that the very same codebase will work everywhere. Our approach is built on the basis of a coding methodology called progressive enhancement, which, simply put, recommends that all web content and functionality be based on semantic HTML that’s usable on any web-enabled device, and advanced CSS- or JavaScript-based enhancements be layered unobtrusively on top of it.
Building sites with progressive enhancement doesn’t necessarily take much more effort, but it definitely requires a shift in your development approach and perspective. Some might argue it’s not worth the effort—that current development methods capture enough of the audience to cover “the majority” of users, and that improving support for web standards among web browsers will close the gap.
However, if recent trends in Internet usage and device development are any indicator, the opposite is true: some of the most cutting-edge, web-enabled devices have browsers with poor web standards support, and the number of older computers or mobile phones that are running outdated and less capable browsers is growing rather than shrinking.
Regardless, the bottom line is that people use a wide range of browsers, platforms, and devices in their daily lives, and they expect their favorite websites and applications to work seamlessly across the lot. Building sites that work only in a handful of specific browsers isn’t a realistic approach when facing this increasingly complex universe of devices, especially when progressive enhancement provides a way to build sites that will work anywhere, for everyone.
But we know just saying these things won’t convince the skeptics. So let’s take a look at some of the facts about the global web audience and current technology, and also examine how common coding approaches can misfire—with results from mild inconvenience to full failure of functionality.
The ever-widening world of the web
It’s easy to forget how quickly and dramatically the Internet has grown and changed our lives. Even a decade ago, web access was limited to a fairly narrow demographic of users, all generally using fairly consistent hardware. Today, the web is truly a global phenomenon, and the diversity of its audience is constantly expanding; and users are accessing the web on a vast array of web-enabled devices.
By understanding the trajectory of who is using the web today, how they get online, and where the growth is most likely to happen tomorrow, we can better plan for this new world where the web is everywhere and used by everyone.
Everyone is getting on the web (or will be soon)
At the start of the Internet boom in the mid-1990s, the majority of Internet users lived in wealthier Western countries, were educated (because the web required technical skill), and tended to be professionals or more affluent individuals, as systems ran on prohibitively expensive PCs that required expensive monthly access plans and a strong infrastructure.
Over the past decade, computers have become much easier to use, and the plummeting cost of hardware, software, and online access has made them far more accessible. With that, the mix of people on the web has shifted to a much more global population with a full gamut of ages, education levels, and socioeconomic classes represented, leading to a democratization of the web’s information and tools.
The brisk pace of Internet adoption continues to drive the growing diversity of people online—the global population of Internet users grew more than 450%—from 361 million in December 2000 to more than 1.78 billion (or more than 25% of the world’s population) in September 2009 (www.internetworldstats.com/stats.htm, as of June 30, 2009). This growth was dramatic across the global stage: Internet users in Africa surged fourteenfold from 4.5 million to 66.9 million, and in Asia grew 6x from 114 million to 738 million, compared with the 4x increase in Europe from 105 million to 402 million (www.internetworldstats.com/stats.htm, as of June 30, 2009).
In the United States, Internet users spread to a broader demographic in the decade, with more than 92% of 18–29-year-olds and nearly half of all seniors online, and a far wider range of education and economic levels. The web is quickly becoming ubiquitous: more than 73% of the U.S. adult population reported using the Internet and email, access in rural areas surpassed 50% (Pew Research Center’s Internet & American Life Project (www.pewinternet.org), and fully 93% of all public elementary school classrooms have Internet access (U.S. Department of Education, National Center for Education Statistics. 2006. Internet Access in U.S. Public Schools and Classrooms: 1994-2005. NCES 2007-020).
But it’s perhaps most interesting to consider these facts: at 798 million users, Asia’s Internet penetration is less than 20% of its population, and Africa’s 66.9 million represent less than 7%, while the U.S. and most western European countries are generally in the 70–80% range. As Internet access continues to grow, the largest areas of potential growth are much more likely to happen across the globe, where users have not only different languages and cultures, but also very different equipment, connections, infrastructure, and access expectations than people in the Western world.
Evolving user expectations
Along with huge growth of the global user base and web-enabled devices, there is an equally dramatic change in what the Internet delivers today. A confluence of new web content and interaction innovations has fundamentally changed user expectations about website behaviors and capabilities. Consider, for example, just this short list of changes since 2000:
• Established online-only businesses like Amazon, eBay, and Netflix introduced much more richly-layered content, embedded media, dynamic interactions, and immersive experiences, which set a new bar for user experience.
• The emergence of user-generated content—from blogs to YouTube, Facebook, Digg, Twitter, and beyond—has democratized website content and structure, and raised users’ expectations of being able to create, reference, and creatively repurpose web content to suit their needs.
• The real-time web has caused people to expect up-to-the-second updates of their social network on Facebook, followers on Twitter, and collaborators on Google Docs or Wave, which has prompted a big move away from the static page-by-page underpinnings of the web and towards an Ajax-powered environment that may never require an old-fashioned page refresh.
• The rise of web-based applications that attempt to offer desktop-quality user experiences in web browsers, like rich data visualizations, drag-and-drop gestures, and rich interactivity, support the overall trend of software being offered as a web service instead of installed on a computer.
• As users now access the web through multiple desktop browsers at work and home and on the move with their mobile phones and other devices, they expect their data to be accessible on any device at any time.
These innovations have transformed the Internet into to a powerful global platform that delivers application-like features and functionality in the browser, and puts the power of instant communication in the reach of all users.
Expanding user accessibility needs
With a significantly broader demographic online, including a larger proportion of older users, and the vast array of new interaction models emerging in advanced websites, there is also a new set of considerations that impact how we design websites.
As people age, they typically suffer from decreased or impaired vision, hearing, and motor skills, all of which are critically important for successfully navigating the Internet. Conditions such as cataracts, blindness, hearing impairments, reduced joint mobility, loss of fine motor control, or hand tremors can make using a traditional website difficult at best.
These older users may require larger type and more contrast, especially for extended reading; it’s critical that websites be structured to allow the adjustment of text settings to suit their needs. Many blind users, and those with more extremely impaired vision, leverage assistive technologies such as screen-reader software programs on their desktops to read application content and web pages aloud; properly structured semantic content and full keyboard support to promote navigation without vision or a mouse are essential to successfully using screen readers on the web. And users with compromised mobility frequently feel more control using the keyboard for navigation rather than a mouse.
In 1998, the U.S. Federal Government passed Section 508, an amendment to the Rehabilitation Act that requires federal agencies to make their electronic and information technology accessible to people with disabilities, and established national standards for accessibility of digital media for people with physical and mental disabilities. Although these rules apply only to government agencies and companies that supply goods and services to the federal government, Section 508 presents a clear set of enforceable standards for providing access to all users, and has become a de facto legal standard that many private organizations have also embraced.
The World Wide Web Consortium (W3C) has been very active in creating specifications for accessibility on the web through its Web Accessibility Initiative (WAI) and related projects. The W3C’s Web Content Accessibility Guidelines (WCAG 2.0) provides both high level principles and a checklist of specific guidelines and criteria for ensuring that websites are accessible. The Accessible Rich Internet Applications (WAI-ARIA) specification provides a set of attributes that can be added to markup (like HTML) to describe advanced UI widgets such as sliders and tree controls in a way that is meaningful to screen readers.
Together, these advances provide both a clear mandate and a set of tools that can be used today to provide full access to the web, regardless of users’ physical abilities. Both building accessibility features into sites and testing on screen readers should be priorities to all developers, because lack of accessibility equates to discrimination in the eyes of users, and possibly of the law.
Consider, for example, Target Corporation’s experience: in early 2005, the National Federation for the Blind (NFB) approached Target, alerting them to the fact that a number of features on their website rendered it unusable for many disabled users. The company claimed that their brick-and-mortar stores were adequately accessible for those users. Unsatisfied with Target’s response, in February 2006, NFB brought a lawsuit against Target, citing a violation of the Americans with Disabilities Act of 1990. After several years in the court, the case settled in August 2009, with Target establishing a $6 million settlement fund, paying nearly $3.8 million for NFB’s legal fees, and agreeing to substantially redesign their website to introduce accessibility features, with usability testing by NFB on a scheduled basis.
While such lawsuits are rare, design and development best practice precedent is being set in this and similar cases that promote accessible coding standards. The guidelines and specifications for creating universally accessible sites are advancing. With the democratization of the web, our designs and code need to be developed for universal access—a web that works for everyone, regardless of their language, culture, age, physical abilities, or technology platform.
Rise of the non-desktop web
As the web’s audience, user expectations, and online content norms have evolved, there has been a parallel shift in where and how users connect online—in particular with the emergence of web-enabled mobile phones, video game systems, and dedicated web appliances.
By 2008, of the 1.4 billion Internet users worldwide, fully 75% had accessed the Internet on a mobile device, and 29% of world Internet access was exclusively on a non-desktop browser (Tomi Ahonen, Thought Piece: Mobile Telecoms Industry Size, 2009, www.tomiahonen.com). The adoption of the mobile phone has been faster than any other technology in the history of invention, and its impact on how we design for the web is just now being felt.
Back in the earliest days of the mobile web, mobile handsets had tiny screens, slow processors, and understood only a simplified version of XML called WML (Wireless Markup Language). Few developers, or users, expected websites to work seamlessly on these devices.
A first wave of web-enabled “smartphones” appeared on the scene around 2000–2002—including the Nokia 9210 Communicator, the Palm Treo, and the first RIM Blackberry and Microsoft Windows CE devices—and ushered in a new level of expectation about real-time access to data and functionality. These devices could access standard HTML sites and even had rudimentary support for JavaScript and CSS. In a very short time, literally hundreds of different models of mobile phones capable of accessing the “real” web emerged and sparked off the mobile web revolution.
By 2009, the number of active mobile phone subscriptions has reached 4.6 billion (“Explaining 4.6 billion mobile phone subscriptions on the planet,” Communities Dominate Brands blog, 11/6/09, http://communities-dominate.blogs.com/brands/2009/11/explaining-46-billion-mobile-phone-subscriptions-on-the-planet.html)—a number that dwarfs the current total population of Internet users. Even though all these mobile devices may not have smartphone-like web browsers, it’s fair to say that mobile is a massive and growing channel that can no longer be ignored when building a website.
Even the definition of “mobile device” is constantly evolving and mutating, to include web-enabled touchscreen tablets, micro-laptops, and other gadgets. Each device has its own unique set of browser capabilities, plugin support, installed fonts, screen dimensions, and interaction norms—from a RIM’s Blackberry thumbwheel and keyboard interaction, to Amazon’s Kindle’s mini-joystick controller, to Apple’s iPhone multi-touch interaction model, and beyond.
A large number of video game systems like the Nintendo Wii, Sony Playstation 3, and Microsoft Xbox all have web browsers available—these systems take liberties with website design to “adapt” it in a way that is usable on a television screen ten feet away with a gaming controller. And other consumer electronics—e-book readers, television sets, home telephones, even clock radios and refrigerators—are gaining web browsers. The diversity of devices on which our designs will appear has exploded.
Expanding “shelf life” of devices and browsers
For each new computer, mobile phone, or gadget purchased, there is a good chance it replaces an older device that is recycled down the tech “food chain.” Millions of mobile phones and computers stay active, either handed down within families, shared with schools and community centers, or donated to all kinds of social programs; many end up in faraway countries via donations to military families or global development NGOs. In the developing world, where materials reuse and recycling is far more common, the vast majority of devices are carefully maintained far beyond their typical “useful” life in the West. With each passing year, an ever-growing number of machines in homes, libraries, schools, and Internet cafes are running “antiquated” versions of browsers that aren’t updated, for various reasons.
Along with this large universe of older devices in current rotation, there is an equivalent group of “fringe” browsers that run on alternative operating systems. Unix-based operating systems are frequently used in low-cost computers like netbook mini-laptops and the One Laptop Per Child (OLPC) project’s XO computer. Technical power users frequently use Unix-based computers that run a wide array of “alternative” browsers like Konqueror, and purely text-based browsers like Lynx, that can render pages very differently than mainstream browsers. Each may have marginal market share individually, but together they constitute millions of web visitors worldwide.
* * *
The massive scale and range of people now on the web, coupled with the shifting expectations of user experience and the explosion of web enabled devices we need to support, translates into an exponentially more complicated design and development challenge than the one designers faced even a few years ago.
The common approach of developing only for a target group of the newest and most popular desktop browsers and ignoring the rest almost surely leaves millions of potential readers, customers, job seekers, dates, or political supporters with a broken, unusable experience. At the same time, we appreciate that it’s daunting for any developer to accept responsibility for testing and debugging sites on even a tiny representative set of the vast array of desktop browsers, mobile phones, gaming systems, and other specialized devices because time and effort are always a constraint in a real-world project.
Still, if you’re not convinced that the standard approach to developing advanced websites is a problem, consider the following real-world cases where current sites fall down.
The landmines of Web 2.0
Many of the more interesting and engaging features in the explosion of Web 2.0 sites and applications developed in the past decade are supported by JavaScript for rich interactivity, Ajax for dynamic data, and advanced CSS.
These advances paralleled the launch of scores of different desktop browser versions over the past decade—and this doesn’t take into account the vast array of web-enabled devices and mobile phones in recent years. While many contemporary browsers embrace web standards, they don’t render the web uniformly, and collectively require a complex system of coding, testing, and occasional hackery to get sites to appear and function in a consistent manner.
There are a number of common web design and development trends that are undermining the promise of universal access that the web is built on.
Browser tunnel vision
To make development and testing manageable in the real world, all companies and individual developers (ourselves included) focus their coding and testing on a specific set of browsers. This is reasonable from a contractual perspective: clients ask us to commit (in writing) that our code will look and function exactly as designed, and we know that not every browser can handle the styles and scripting that a modern site design requires. So part of our agreement involves testing the code in some agree-upon list of browsers or environments, depending on the project.
But what about all the users who aren’t using a supported browser? Is it acceptable to exclude them from accessing the site and display a message asking them to upgrade their browser? Many people don’t upgrade their browsers—either because they’re not technically savvy enough to upgrade, aren’t allowed to install software on their machines for security reasons (especially true in corporate environments), or are tied to a legacy browser because a crucial-to-them web application works only in that specific browser.
It’s easy to dismiss users in non-supported browsers as unimportant because they represent a marginal percentage of the audience, or because it’s assumed they are generally less savvy or technically adept and, therefore, not a target user. But poor browser capabilities are not limited to outdated devices or to Luddites: Amazon’s Kindle, a device commonly considered to be “cutting edge” and used by very demanding early adopters, has a monochrome display and a text-based browser that offers only limited CSS and JavaScript support as “experimental” features.
Enforcing access to a specific set of target browsers through user agent detection is fundamentally unreliable. For example, many versions of the popular Blackberry smartphone provide a preference that lets users identify their browser as either Blackberry, Firefox, or Internet Explorer, precisely to get past these developer roadblocks.
This leads to situations where developers may take risks with their use of JavaScript and CSS, assuming that they’ve locked out all the “bad” browsers, and will deliver a very broken experience to anyone who switched a preference setting to gain access.
The notion of a list of supported browsers oversimplifies a host of other assumptions: developers commonly assume that supported browsers will have all features enabled—like images, CSS, cookies, JavaScript, and plugins like Flash, Java, or Silverlight—and that all of these enabled features will behave as they expect. What if a user has a supported browser but decides to disable cookies or JavaScript for security or privacy reasons? What if a user has disabled CSS or images in their mobile device to make pages load faster? When developers estimate that a chosen list of supported browsers will cover 95% of the general web population, they overlook situations where users technically have a supported browser but have disabled a feature that is critical for the design to work.
In the real world, code probably fails far more often than developers know (or care to admit) because the majority of testing happens in a relatively safe and controlled environment—a limited set of modern browsers in their default configuration, on a “typical” screen resolution, at default font size. The real world is much more unpredictable and varied. The notion that we need only consider a small set of “target” browsers creates a false sense of security. This “tunnel vision” prevents us from really seeing all the browsers and devices that we need to support and working on ways to make our code more compatible and bulletproof.
“JavaScript required” may leave many users out
Many sites now rely on JavaScript for essential functionality, like populating page content with Ajax or submitting and validating forms—which means that when scripting isn’t available, entire pages or features can break completely.
A search for statistics on the percentage of users who have JavaScript enabled yields numbers from 85–98%; the most quoted source, W3schools’ browser statistics site, estimates that about 5% of Internet users have JavaScript disabled. (At current internet usage rates, this translates to roughly 83 million people!) We work with several clients who use custom enterprise browser configurations with selected JavaScript features modified or disabled for security reasons; these browsers will properly “register” as JavaScript enabled, but not all sites or pages will function.
Many popular JavaScript- and AJAX-powered sites—including Adobe’s e-commerce store, the travel-booking site Kayak, and the project-management tool Basecamp—simply require JavaScript for core functionality, and present an error message when scripting isn’t enabled.
These error messages usually tell the user to turn on scripting and use a supported browser. But what if a person is at the airport and needs to check alternative flights, or see the status of a project, on an older Blackberry or Palm Treo that doesn’t support JavaScript? Downloading a new browser isn’t an option.
A surprising number of large e-commerce sites build essential features that drive revenue in a way that works only when scripting is available. On the Sears.com website, newly relaunched in the fall of 2009, when a customer either searches for a product or navigates to any product listing page (for example, Home > Appliances > Microwaves > Countertop) without JavaScript, the results area that should display products remains blank except for an Ajax “loading” animation.
The page is served with only a placeholder spinner animation, which is clearly intended to be replaced with a list of products by an Ajax request after the page loads; there is no meaningful markup on the page when it loads. The search filters and featured product blocks are also JavaScript-dependent. For users without scripting, the Sears site completely fails in its primary purposes: helping shoppers do research and buy products.
Although it would be nice to assume this is an isolated situation, it’s a widespread problem. On the current Walmart.com site, every Add To Cart button is added to the page with Ajax; without JavaScript, there are no purchase-related buttons. Both the Toys R Us and The North Face sites have an Add To Cart button on their product detail pages, but clicking that button calls a JavaScript function that does nothing at all in a browser with scripting disabled.
All of these are lost revenue opportunities that could have been easily avoided by simply including a functioning Add To Cart button in the page that submits a simple form.
Assuming CSS is another potential a point of failure
Assumptions about CSS support, either alone or combined with JavaScript, introduce another whole range of potential failures.
Many older desktop browsers don’t render CSS according to web standards. On popular smartphones like the Palm Treo and older Blackberry devices, users often disable CSS completely because of the browser’s poor CSS support. We sometimes see complex and advanced CSS applied to the page and served to every device. When rendered incorrectly by browsers with spotty or no CSS support, the page may not look as intended, and it could even cause sections or the entire page to become unusable if elements end up positioned incorrectly or styled illegibly.
Compounding this issue, developers sometimes rely on JavaScript to add or manipulate CSS styles in order to make a page functional. This is a common point of failure: if either CSS or JavaScript isn’t properly supported, the page may be rendered unusable, regardless of how nicely structured the markup may be under the covers.
On the Ford cars home page (www.fordvehicles.com), both the global navigation bar and footer links rely on JavaScript to position them correctly on the page. Without scripting, the global navigation is invisible, and the footer navigation links are positioned over the main product image, making much of the page illegible and unusable.
The international landing page for Nike.com has a JavaScript- and Flash-enabled list of countries to route shoppers to a country-specific site. With scripting disabled, a customer sees only a blank, black page that completely prevents them from shopping. Ironically, in the HTML source for the page, there are perfectly usable links for each country, but they’re hidden with hard-coded CSS to make room for the JavaScript enabled experience they assume everyone will see. This simple choice denies untold numbers of potential shoppers every day for Nike.
The black box of plugins
Plugins like Adobe Flash, Microsoft Silverlight, and Sun Java are popular with developers and many users—they can provide powerful capabilities like visualizing interactive charts, maps, and other information; playing media; connecting with a computer’s file system; and more. But because they can require manual installation and updating by users, and are not supported on every platform and browser, they frequently offer the frustrating “update your system” roadblock to users without the most current version installed.
On mobile devices, plugin support is currently piecemeal, as carriers, handset manufacturers, and plugin developers work to balance performance with the less powerful processors found in mobile devices. For example, Apple has steadfastly refused to allow Adobe Flash support in the iPhone’s browser, meaning that the tens of millions of iPhone users cannot currently access any form of Flash content.
In addition to concerns about mobile access, any content delivered with a plugin is stored within the proprietary plugin code structure, so despite the efforts of plugin makers to improve accessibility, the content is not as accessible to screen readers or search engines as it would be if coded with simple, semantic HTML.
Finally, there is small but alarming trend that Adobe Flash and PDF are being targeted as the most popular vectors for malicious tampering, as they have generally broad support on the most popular browsers and platforms. This emerging security risk may have implications for both user adoption and corporate security standards that will influence users’ willingness to access plugin-based content. (Sources: “Adobe Flash’s security woes: How to protect yourself,” Computerworld, 12/14/09, www.computerworld.com/s/article/9142223/Adobe_Flash_s_security_woes_How_to_protect_yourself?taxonomyId=63, and “Adobe to patch zero-day Reader, Acrobat hole,” CNET news, 12/16/09, http://news.cnet.com/8301-1009_3-10416816-83.html.)
New devices introduce unanticipated interaction norms
Many popular mobile phones have excellent browsers that rival the latest desktop versions in terms of CSS and JavaScript capabilities, but have introduced radically different ways for users to interact with the page than on standard desktops—which can have significant usability implications.
For example, touchscreens that support multi-touch gestures have emerged as the new standard for interactions in many mobile devices. The combinations of tap and drag gestures on a touchscreen introduce a new set of interaction norms that allows users to zoom, click, and scroll pages. However, there are a few important interactions that an iPhone or Android user cannot duplicate easily in a multi-touch environment:
• On a multi-touch mobile device, the gesture of dragging a finger across the screen is used to pan or scroll the visible area of the web page. Since the drag gesture is already used for panning around the screen, there isn’t any gesture to let users drag and drop items on the screen. If you build an interactive experience where users can add items to their cart only by dragging, this feature won’t work on these advanced mobile devices.
• Some web applications mimic the desktop multi-select capability by clicking items with the mouse while pressing the Control or Shift key on a keyboard. On a touchscreen, any interaction that requires simultaneous keyboard and mouse clicks is not supported without some custom workaround.
• Sites that break pages up into small scrolling panels by setting the CSS overflow or using frames—like an Outlook-style email reader with a list view and reading pane, for example—won’t work on an iPhone, as there are no persistent scrollbars within the web browser. In fact, the iPhone could render the whole interface perfectly, but the internal scrollbars for the message list or detail pane won’t be displayed—the user would need to intuit that they aren’t seeing the full list or message and know to use a two-finger drag gesture to scroll within the sub-pane.
* * *
Many site developers assume that everyone who can render the enhanced experience has all the features and tools to fully support it, and has a desktop browser with a keyboard and mouse for input. But we hope we’ve convinced you that, increasingly, these are dangerous assumptions to make.
As companies and individuals launch new sites, or build new capabilities into their existing systems, they face important decisions about how to design and implement the front-end code. Since the web is inherently an unpredictable environment, assumptions about browsers and plugins deliver a false sense of security. In reality, any technology used in a web page that isn’t simple HTML markup will break somewhere, and could ruin the user experience.
To avoid these pitfalls, any content or transaction that is essential to the core purpose or business of a site should be developed to work on any browser that understands basic HTML—this is the cornerstone of the underlying design of the web, and the key goal of universal access. CSS, JavaScript, cookies, and images can all enhance some browser experiences, but inhibit or break in others; a design approach that makes them secondary and optional is the one that will deliver an optimal experience for the broadest possible spectrum of users.
Progressive enhancement to the rescue
When faced with the incredible range of different users and devices we needed to support on our day-to-day projects, we began to wonder how to provide a site or application that would work for everyone, feature the most advanced interface elements for those who were capable, and still be manageable to develop and test for real-world client projects. We needed a pragmatic approach that provides a solid, usable baseline experience for any device, and reserves the richly designed features that require the tight coordination of JavaScript, CSS, and plugins for a subset of popular, modern desktop and mobile visitors.
What we really wanted was a “magic bullet:” a single, manageable codebase that would work everywhere, created with the cleanest, most efficient and future-compatible development approach.
We believe we’ve found a near-perfect solution with progressive enhancement. First coined by Steven Champeon and Nick Finck at the March 2003 South by Southwest conference (“Inclusive Web Design for the Future” by Steven Champeon and Nick Finck, delivered 3/11/03 at SXSW, http://hesketh.com/publications/inclusive_web_design_for_the_future), progressive enhancement is as much a mindset as a methodology. It focuses first and foremost on content and functionality. The goal is to build a perfectly functional and usable page that uses only the expressive potential of HTML semantics, creating a page that is accessible from the start and guaranteed to work on any web-enabled device—mobile phones, gaming systems, web-browsing refrigerators, and anything else you can think of.
Only after the HTML markup is as descriptive and clear as possible do we develop CSS and JavaScript—both written to external files and then unobtrusively applied to the HTML markup to transform it into a rich, interactive experience. We avoid inline styles or event handlers whenever possible. The key to progressive enhancement starts with the careful separation of content (HTML), presentation and styles (CSS), and behavior (JavaScript), which allows us to deliver a workable and appropriate experience for each browser.
We’ve been using progressive enhancement as a cornerstone of our development process for years, and have realized that it is a currently practical and future-compatible methodology for site development:
• It allows for “universal access,” not only by providing wide accessibility for screen readers and other assistive technologies, but also for users with JavaScript or CSS disabled or for outdated and less capable browsers.
• It promotes coding clarity: thinking from the bottom up encourages cleaner and more modular code, where each functional component has a single purpose and can be reused throughout the interface in multiple contexts.
• It keeps things centralized and simple, allowing organizations to maintain a single, unified codebase that is compatible across all desktop, mobile, and video game devices.
• It positions sites for future compatibility: the simplest version that works today will continue to work tomorrow, and features included based on capabilities can be easily adapted without requiring major retrofit or removal of fussy hacks.
• It allows for a simpler interface with the back-end. We always use native, fully functional elements to serve as the single data connection to the server, and use scripting to create proxy connections to keep enhanced custom elements in sync with the basic elements.
• It allows for a single, common codebase across experiences. Each site we develop can use the same HTML page for both the basic and enhanced experiences because the only difference is how CSS and JavaScript are layered on top of this foundation markup.
Over the past few years, progressive enhancement has been quietly adopted by some of the biggest and best sites on the web, precisely because it allows them to reach the widest possible audience. Browse Google, Facebook, Amazon, or Digg with JavaScript and/or CSS turned off, and you’ll see that the sites will work surprisingly well. Each site may approach progressive enhancement a bit differently, but each achieves the same goal of delivering a usable experience to anyone who visits.
In most cases, implementing progressive enhancement and delivering on the promise of universal access doesn’t take more work; it’s mostly a matter of unlearning some bad habits, looking at design and development from a different perspective, and ensuring that a lot of small things that need to be done right are done right.
The goal of this book is to help anyone develop a universally accessible site by applying simple, workable progressive enhancement techniques that have been tested in the real world.
In the first section, we’ll review our approach to implementing progressive enhancement, including a different way of thinking about planning designs, and our unique methodology for testing the capabilities of each browser before applying enhancements. Then we’ll review the HTML, CSS, and JavaScript best practices that will arm you with all the tools you’ll need to build sites a new and better way.
After that, we’ll look at a dozen specific interface components or widgets and take you step by step through a process to show the specific markup, style, scripting, and enhanced accessibility features you’ll use when working with progressive enhancement. These examples individually provide specific how-tos, and collectively represent a set of principles and methods that can be extended to other coding situations to broadly apply progressive enhancement in any situation.
We’ve used these techniques on our own site and in a number of client engagements, and have found that our approach helps to make progressive enhancement practical and actionable. We hope that by the time you’ve finished this book, you’ll agree.