Chapter Seven. Building Widgets with Progressive Enhancement

When building web sites and applications with progressive enhancement, it’s important to use the x-ray perspective to decide how the basic and enhanced experiences work together, and then follow the best practices for coding the markup, CSS, and JavaScript in an accessible way to provide the best possible experience to the widest range of browsers and devices.

Synthesizing these best practices can be a bit daunting the first time through. So, in this section, we’ll walk step-by-step through detailed examples of a dozen commonly used interactive widgets—like a tabs control, slider, data chart, and dialog—and show how to build them according to our progressive enhancement process.

Before we dive into code examples, we’ll take a moment to summarize the general coding approach we’ll follow for these widgets, provide an overview of which components we cover, and describe the structure you can expect to see in the chapters in this section.

How the widgets are coded

There are several valid ways to markup a page with HTML, CSS, and JavaScript. In the following chapters, we use standard approaches and syntax that are well documented and easy to follow.

For the foundation markup, we use XHTML syntax, finding its disciplined and precise rules—that all element tags are closed and all attributes quoted, for example—make it easier to read and replicate.

We use elements primarily from the latest official HTML specification, HTML 4.01. We consider this “safe” HTML because, as the approved spec since April 1998, it’s universally supported across the widest range of mobile and desktop browsers, including the more “creative” browsers that run on gaming systems and household consoles. Equally important, all the elements we use in our examples will continue to be supported by the next HTML specification, HTML5, so this markup is both backward and forward compatible.

At the time of this writing, the HTML5 specification is in draft form. Though not fully approved, we use a number of HTML5 elements and attributes throughout the widget examples that fall into two broad groups:

• A few attributes—like the input type= number and the data prefix—add information that we can use to build a smarter enhanced experience, add greater semantic value to markup overall, and are either safely ignored by browsers that don’t understand them or have a built-in fallback HTML4 element. These are safe to use in foundation markup.

• A small group of HTML5 features—like the canvas and video elements, for example—offer robust standards-based functionality, are likely to be included in the official HTML candidate recommendation, and are already being adopted by several contemporary browsers. In the following widget examples, we recommend using many of these features in your projects today, and we’ll demonstrate how best to do that.

The WAI-ARIA 1.0 specification is also in draft form at the time of this writing, but is well supported in several of the more popular screen-reader software packages. We apply WAI-ARIA accessibility attributes extensively to markup for both the basic and enhanced experiences to help ensure that our code is well understood by assistive technologies and well positioned for future accessibility advances.

All widget examples use style properties specified in the latest CSS specification, CSS 2.1 (www.w3.org/TR/CSS2). When possible, we include newer properties proposed for the next revision, often referred to as CSS3, like border-radius for rounded corners or text-shadow for a drop shadow effect (www.w3.org/Style/CSS/current-work#CSS3). Currently, many of these properties will render correctly only in a subset of modern browsers, including the latest versions of Firefox, Safari, and Opera. In browsers that don’t support them, they are simply ignored, so we can confidently use them for style enhancements, knowing they will cause no harm.

Finally, our script examples are based on the jQuery JavaScript library, an open-source library of helpful JavaScript properties and methods for writing very concise yet powerful functions. We use jQuery because its selector and method syntax (its conventions for locating and acting upon specific DOM elements) are particularly easy to read, and can quickly convey the logic behind particular scripting actions. Documentation for the jQuery library, including a full reference of accepted selectors and available methods, is maintained at jquery.com. (Full disclosure: Filament Group actively contributes to the jQuery UI widget library and, collectively, belongs to the jQuery leadership team.)

Navigating the widget chapters

Each chapter in this section of the book covers a specific widget example and, when possible, reviews common variations of that component. The widget chapters are organized into two groups by their primary purpose:

• The first six chapters present content organization widgets, which arrange information on the page so that it can be selectively shown/hidden (collapsible content, tabs, tooltip, dialog, tree), or displayed as a data visualization (charts).

• The second six chapters feature data input and submission widgets that provide convenient, and often more efficient, ways to collect user input (buttons, custom check boxes and radio buttons, slider, list builder, select menu, custom file input).

Within each chapter, we follow a general format: review the widget’s target design with an x-ray perspective and map functional pieces to standard HTML elements, and then write foundation markup, apply safe styles, and layer on style and script enhancements.

When constructing each widget, we follow a few key principles to ensure that both the basic and enhanced experiences deliver the appropriate functionality and are universally accessible to those on screen readers, mobile devices, and desktop browsers alike:

• We always start with semantic HTML for the foundation markup and logically define valid attributes. When the target design allows, we’ll use this markup for both the basic experience and as the starting point for any style or script enhancements, and when possible, we’ll also use it as a content source to help configure an enhanced widget.

• To ensure that every enhanced experience is as fully accessible as the native markup on which it’s based, we build in ARIA attributes, keyboard access, and any other expected behaviors based on existing precedents (similar form controls, desktop conventions, or WCAG guidelines), and we recommend thorough testing with screen readers like VoiceOver, NVDA, WindowEyes, and JAWS.

For data input and submission widgets, specifically, we’re careful to always start with a functional HTML form control to ensure that, in the absence of any CSS or JavaScript enhancements, the component will function as needed and be accessible to all users on any device. We add the fewest enhancements necessary to make the element look and act like a richly styled control, without altering how the user interacts with it—for example, in Chapter 15, we show how to customize checkbox and radio button elements using standard input and label elements along with CSS and minimal JavaScript.

When it’s not possible to enhance a standard form control, we make sure that the enhanced component (whether it works in tandem with the original form element, or replaces it entirely in the user experience) always maintains a continuous connection to the native input for data submission. We do this by scripting a “proxy” connection—any time that either the basic native form control or the enhanced custom widget changes a data value, this script captures user input and updates the other component to keep them continuously in sync. To ensure the simplest and cleanest integration with back-end server logic, we always keep the original native form element in the markup to submit form data.

When running script enhancements that manipulate elements on the page, we do so as soon as the markup is ready, so the enhanced experience appears in a seamless way, and to prevent errors associated with running scripts before the elements are present. To do this, we use jQuery’s ready method. When not otherwise specified, assume that any DOM-related code presented in our widget chapters is called within this ready method. (We reviewed the ready method in detail in Chapter 5, “Scripting enhancements and interactivity.”)

Example code for download

For every widget in the following twelve chapters, we’ve developed markup, styles, and plugin scripts—for experimentation and to include in your projects. At the end of each chapter, we provide specific instructions or tips for how to download and use a full-featured version of the code described in the widget example. All code that accompanies the book is available at www.filamentgroup.com/dwpe.

All code and plugins are provided as open source and released under the MIT open source license for both commercial and non-commercial use (www.opensource.org/licenses/mit-license.php).