Chapter Six: Accessibility

When Tim Berners-Lee created the foundations of the World Wide Web in the early 1990s, he emphasized the importance of its inclusiveness and universality. Accessibility to all people regardless of disability is a fundamental part of this vision.

For over a decade, the W3C has been developing protocols to help make the web as accessible as possible, and has included accessibility factors in specifications for standards such as HTML and CSS. Simultaneously, legislative bodies around the world have implemented accessibility laws and regulations that affect the web as well as the physical environment, and which often directly reference these W3C specifications.

Yet accessibility is often overlooked by web developers. At best, it’s an afterthought, a list of formalities to be checked off—with as little effort and expense as possible—after the “real” work is done.

But a commitment to accessibility should be a core part of the ethics of our emerging profession: something we willingly strive to achieve, not something we do grudgingly and only when legislation requires it. If you’ve had much contact with someone with a disability, you may understand how difficult it can be to gain access to vital information, social networks, and services. If you haven’t, consider limiting your own access so you can experience for yourself some of the challenges faced by people with disabilities. Spend a week making all your purchases and commercial interactions online. Use a screen reader to check your email and catch up on your daily reading. Navigate with only your keyboard, or only your mouse. You’ll quickly gain an appreciation for the immense challenges most websites and internet interactions pose for people with disabilities—challenges you are in a position to do something about.

The leading role that the web has played in improving the lives of so many people with disabilities is one of the reasons I’m a web developer. That won’t be true for everyone, but whether you’re motivated by altruism or by the threat of lawsuits like those involving Target and RiteAid in the U.S. (and going back to the Australian Human Rights and Equal Opportunities Commission legal action involving the Sydney Organising Committee for the Olympic Games in 1999), you’ll find that accessibility is a core goal of professional web development.

Fortunately, it’s much less confusing and difficult to achieve than you may have been led to believe.

In this chapter, we won’t be able to cover accessibility-related areas in great detail, but we’ll cover the central issues, recommendations, and technological challenges, and look at some straightforward steps we can take to help make our sites as accessible as possible with little additional effort.

The Business Case for Accessibility

There’s a solid business case to be made for accessibility in web development. Accessible development can improve the lives of those who visit our sites, but it also translates into direct cost savings (fewer people calling customer service phone lines, for example), and lets businesses reach many more people, thus increasing sales and revenue. The number of people with disabilities in our communities is far greater than most people imagine. For example, the U.S. Department of Health & Human Services recently reported that one in five U.S. citizens has some form of disability, and one in eight has a severe disability. When we speak about people with disabilities, we’re talking about tens of millions of people—and about a market segment that is often more likely to use e-commerce than many other groups. Addressing the needs of this community can directly impact the bottom line of a company.

Beyond these direct commercial benefits, accessible development techniques can also have many other positive results. Google and other search engines are, in a sense, blind. When they index a site, the only text they perceive is actual text—not images or Flash files that only people without visual disabilities can interpret as text. Sites that use good clean semantic structure, avoid table-based markup, and embrace other accessibility practices are, therefore, likely to benefit from improved findability and search engine ranking.

The Global Legal Framework

Throughout the world, anti-discrimination legislation addresses discrimination against people with disabilities. Such legislation generally covers many aspects of life, but increasingly also expressly addresses the web and website accessibility. The issue is complex, and any attempt to provide a simple overview will likely be more confusing than not. You’ll find sources of more complete information on the situation worldwide at the end of this book.

Accessibility and the W3C

Since its early days, the W3C has attempted to develop accessibility recommendations, guidelines, and policies, and to build accessibility directly into standards like CSS and HTML. In 1999, the W3C published the Web Content Accessibility Guidelines version 1 (WCAG 1), and in 2008, they published an updated version, WCAG 2. Additionally, to address the growing need for accessibility guidelines for web applications, the W3C’s Web Accessibility Initiative (WAI) developed the Accessible Rich Internet Applications Suite (WAI-ARIA), a standard we’ll turn to shortly.

WCAG 1

Published in 1999, in the days of version 4 browsers, WCAG 1 was the first major attempt to codify a set of practices to ensure more accessible websites. The goal of WCAG 1 was to show “how to make Web content accessible to people with disabilities” (www.w3.org/TR/WCAG10).

WCAG 1 is divided into fourteen guidelines, each of which is subdivided into checkpoints, and each of these checkpoints has a priority, from A to AAA (usually called “triple A”). Conformance to WCAG 1 guidelines can be measured by conformance to these checkpoints. A document has a conformance level A if it meets all of the level A checkpoints. Likewise, a document is considered AA (“double A”) if it meets all the AA checkpoints, and triple A if all of the AAA checkpoints are met.

Before we delve a little more deeply into these guidelines and checkpoints, it’s worth noting that AAA compliance is widely considered to be difficult to attain, and not always worth the effort: many AAA checkpoints are highly subjective, and AAA compliance produces little practical value. As a result, AA compliance is the level most experts (and some official government guidelines) recommend aiming for.

Guidelines and Checkpoints

As noted above, each of the fourteen guidelines of WCAG 1 has several checkpoints. In this chapter, we’ll examine only those checkpoints that most commonly cause difficulties. The WCAG 1 guidelines (and an accompanying “Techniques” document) are quite straightforward, so don’t be afraid to read them yourself.

Guideline 1: Provide Equivalent Alternatives to Auditory and Visual Content

This guideline addresses the needs of people with hearing or visual disabilities. One of the most common errors developers make is to omit appropriate alt content for images. In HTML 4, all img elements must have an alt attribute, though the attribute value may be empty (that is alt="") when an image is purely decorative—though we should really be using CSS, rather than markup, to add such images.

Rich audio and video content accessibility requires far more than simple textual equivalents, and the requisite captioning techniques go quite some way beyond the scope of this book. You’ll find links to resources on audio and video captioning and related accessibility techniques at the end of this book.

Guideline 2: Don’t Rely On Color Alone

This applies to CSS more than HTML, as style should always be applied using CSS, not presentational markup. Up to eight percent of the male population has some form of difficulty discerning the difference between colors, while people using monochrome devices (such as Amazon’s Kindle) will not be able to discern between many different colors. Instead of, for example, using green to indicate safe and red to indicate danger, use shapes, text labels, and other indicators to convey the information.

Guideline 3: Use Markup and Style Sheets and Do So Properly

This guideline suggests that we should use the technologies of the web according not just to the letter of the law (table-based layouts will, after all, validate), but according to its spirit as well. Checkpoints here include ensuring documents are valid, relative units like em and % are used instead of px in CSS, and the appropriate semantic and structural elements of HTML are used (for example headings, lists, quotations, and so on).

Guideline 5: Create Tables That Transform Gracefully

Tabular data can cause significant problems for people using assistive devices like screen readers. Guideline 5 has several checkpoints to help improve the accessibility of such data.

These checkpoints include using row and column headers in data tables, and for complex data tables, use features like thead, tfoot, and tbody to group rows, col and colgroup to group columns, and the axis, scope, and headers attributes to show the relationships between cells and headers. We look at techniques for improving the accessibility of data tables later in this chapter.

Guideline 9: Design for Device-Independence

Guideline 9 focuses on the importance of being able to use a site or page no matter what input device you’re using—a keyboard, a voice input device, and so on—instead of only with a mouse.

These are just a few of the guidelines, but many major sites fail to comply even with this limited set. Conformance to WCAG 1 level AA is mostly straightforward, and is usually machine testable using tools we’ll cover in a moment. It is, therefore, relatively easy to assess a site’s level of conformance with these guidelines—and developers have little excuse for failing to meet them.

Quality assurance tools for WCAG 1

Not all of the WCAG 1 guidelines can be machine tested—several require human judgment to measure conformance—but for those guidelines that are machine testable, a number of tools exist to make the process easier. They include:

• CynthiaSays from HiSoftware—www.cynthiasays.com

• HERA—www.sidar.org/hera/index.php.en

• WAVE from Webaim—wave.webaim.org

• Total Validator—www.totalvalidator.com

• ATRC Web Accessibility Checker—www.achecker.ca/checker/index.php

WCAG 2

WCAG 1 is focused on the web technologies that existed when it was published. In the years that followed, some of these technologies matured, while others—like DOM scripting—became more prominent. The second release of WCAG, WCAG 2, is structured rather differently.

Principles, Guidelines, Success Criteria, and Techniques

WCAG 2 was developed with the aim of creating guidelines that are less bound to particular technologies, more objective, and thus more readily testable (by software or people), and more adaptable to changes in web technologies. According to the Web Accessibility Initiative, WCAG 2 is intended to apply to “different types of Web technologies and to more advanced technologies” as well as technologies that “develop in the future.” It is also designed so that compliance with its success criteria will be “more precisely testable with automated testing and human evaluation” (www.w3.org/WAI/WCAG20/wcag2faq.html).

Where WCAG 1 was a series of guidelines with associated checkpoints, WCAG 2 is divided into four major principles. Each principle has a number of guidelines, and each guideline has several checkpoints, called success criteria. Each success criterion is associated with sufficient techniques (recommended ways of meeting the success criteria) and advisory techniques (methods that are not by themselves sufficient to meet the criteria, but which are still encouraged). None of these techniques are required to meet the criteria. The “Techniques for WCAG 2” document also identifies common failures, which the working group defines as “authoring practices known to cause Web content not to conform to WCAG 2.0.”

WCAG 2 is not without its critics in the accessibility arena, and its uptake as the primary reference criteria for web accessibility has been slower than the W3C might have expected. It does appear, however, that it will eventually supplant WCAG 1 as the primary guideline for web accessibility. For an overview of some of the industry’s concerns with WCAG 2, see Wikipedia’s entry on web accessibility, which at the time of this writing was surprisingly good (en.wikipedia.org/wiki/Web_accessibility#Criticism_of_WAI_guidelines).

WCAG 2 is a much larger document than WCAG 1, and has been criticized for being vague and jargon-filled—for a taste of these criticisms, check out www.alistapart.com/articles/tohellwithwcag2 and www.webcredible.co.uk/user-friendly-resources/web-accessibility/wcag-guidelines-20.shtml. It is, however, accompanied by very detailed documentation to help developers understand and meet each success criterion. It’s also designed so that pages that currently meet WCAG 1 A and AA criteria should mostly continue to meet WCAG 2 criteria with little or no additional effort.

The depth and complexity of WCAG 2 put its details far beyond the scope of this book, but you’ll find links and other resources related to the guidelines in the Resources section at the back of this book.

Quality Assurance Tools for WCAG 2

Because WCAG 2 is still in its relative infancy, there are far fewer automated tools available for it than for WCAG 1. Of the list of tools for WCAG 1 testing discussed earlier, only ATRC Web Accessibility Checker also does WCAG 2 testing.

ARIA

As web content and sites have become more sophisticated and application-like, it has become increasingly challenging to maintain, and even to define, accessibility. The WAI’s Accessible Rich Internet Applications Suite, or WAI-ARIA, more commonly called ARIA, is designed to meet exactly this challenge. ARIA is a set of HTML extensions that can be used to annotate elements, thus identifying each annotated element’s role, states, and properties in ways that increase a page’s accessibility.

In this section, we’ll take a quick look at what ARIA enables to get you started. Although ARIA is still in its early days, there’s at least some non-trivial support in all contemporary browsers, including IE 8 as well as a number of screen readers, and it seems clear that browser developers are solidly behind the technology. ARIA is here to stay.

Keyboard Access

To be accessible, a page or web application needs to be fully usable with devices other than a mouse. ARIA enables applications and pages to be used via a keyboard—no mouse required.

In HTML 4, focus is a term that describes which element on a page is first in line to receive input from the user’s keyboard or other input device. A limited number of elements such as a, area, button, input, and select can receive focus, and users can press the tab key to cycle through these elements. The tab order of these elements (the order in which they receive focus as the user presses the tab key) is determined by their order in the HTML source, or by the tabindex attribute, which specifies via an integer the tab order: the lower the number, the earlier the element comes in the tab order.

In HTML 4, it is possible for developers to create their own application controls, or widgets, as they are called in ARIA, with elements that don’t receive focus, and thus cannot be used via the keyboard alone. With ARIA, any visible element can have a tabindex, and thus can receive focus and be used with the keyboard.

This aspect of ARIA is now supported in IE 8, Opera 9.5, Safari 4, and Firefox 3.5.

Roles

HTML largely relies on element names to provide semantic information about documents; although clever developers use the class and id attributes to add additional information about elements, this use is merely conventional, and isn’t an official part of HTML. As such, HTML is impoverished in terms of its semantic capabilities. ARIA extends a feature of XHTML 1.1, the role attribute, to allow developers to describe the function an element plays, in addition to what it is. For example, lists are li elements, but can play the role of—among other things—navigation. ARIA provides a set of possible values for the role attribute: a set of names for the types of roles that elements can play. To get technical, it provides an ontology for role.

By using the role attribute to describe the role played by a particular element, developers can allow browsers that understand ARIA roles to better communicate the structure of a document to the user. The role attribute can also provide standard, user-expected behavior and appearance for specific types of controls—checkboxes, for example—that are implemented by the developer using elements other than the expected HTML element (which would be <input type="checkbox">, in this case).

The roles of ARIA fall into a number of categories including:

• Landmark roles, which describe regions of a page for navigational purposes. These roles include application, banner, main, navigation, and search.

• Document structure roles, which describe the part played by the element in the structure of the document. These roles include navigation, section, note, and heading (as we’ll see in Chapter 11, these are often closely associated with new structural elements of HTML5).

• Application structure roles, which describe the part an element plays in the structure of an application, including alert, alertdialog, progressbar, and status.

• User interface elements such as treegrid, toolbar, and menuitem.

• User input roles like checkbox, slider, and option.

Using role is simple: we add one of the defined role values as a value of the role attribute of an element, just as we might add a class value. For example, suppose we want to use an input element of type image as a button. We’ll just add a role of button to describe the role this input element is playing:

Just what a browser will do with the information that this is a button is left up to that browser’s developers. But the information is now there, and we can imagine how browsers and assistive devices might make use of this knowledge for the benefit of not only users with disabilities, but all users.

States and Properties

In addition to allowing developers to annotate the roles an element plays, we can also explicitly declare the state of an element—for example, whether it is currently pressed—as well as other information about that element. States provide dynamic information such as whether or not a checkbox is checked, whereas properties provide information that is essential to an object’s nature. That said, the distinction between properties and states isn’t that important, since they work in very similar ways. It is, however, important to note the difference between states and properties on one hand and the role attribute on the other. When we use role, we apply values to the role attribute itself, but there are many state and property attributes, and each has its own name—in other words, there’s no ARIA attribute named state or property. ARIA property and state attribute names include the aria- prefix: the aria-disabled state, for example, which can take the values true and false, and the aria-flowto property, which identifies the next element in the recommended reading order.

Returning to the input example, if the element in question were a button that toggled between two states (pressed and unpressed), we could communicate this using the ARIA state aria-pressed.

We could then change the aria-pressed using JavaScript when the element was clicked or received an enter keydown event.

CSS and ARIA

All modern browsers, including IE 8, allow us to style elements based on their ARIA properties and states (and their role attribute values) using attribute selectors. For example, to change the background color of an element when that element is pressed, we’d use the following CSS:

Adding ARIA roles, properties, and states to a website or application requires extra work, but not much more than we’d already do if we used class or id values to accomplish the same tasks. And instead of having to come up with our own approach to capturing the state and properties of a widget or other part of a page or application, we can simply reuse this well-thought-out, standardized approach. Not only will we be helping improve the accessibility and overall usability of our part of the web, we’ll be writing more maintainable and consistent code as well.

Because developers are increasingly using libraries and frameworks like Dojo, JQuery, YUI, and others we touched on in Chapter 5, and because these libraries increasingly support ARIA, much of the effort to increase support for ARIA is already being done for us by the developers of those libraries. Some of the efforts in this area include:

• JQuery—The core team has begun the work of supporting ARIA, and there is a plug-in, jARIA, which adds full support for setting and getting roles, properties, and states via JavaScript using JQuery syntax.

• Dojo—The Dojo 1.0 toolkit has full ARIA support for the core DojoX widget set.

• YUI—A number of the YUI widgets include support for ARIA.

Browser and Assistive Device Support

So what level of support is there in current browsers for features in ARIA? We’ve already seen that tabindex and the ability for any visible element to receive the focus is widely supported, including in Internet Explorer from version 5 on. Here’s the story for other features:

• IE 8 includes support for ARIA roles, properties, and states.

• Firefox 3.5 has the most comprehensive support for ARIA of all contemporary browsers, including roles, properties, and states.

• According to Opera Software, “Opera 9.5 supports parsing ARIA in HTML... This support is experimental, while the ARIA standard stabilizes.”

• Safari 4 has limited support for ARIA, supporting a number of common roles, but not states or properties. Because Safari supports CSS attribute selectors on any attribute, whether it is part of a current HTML standard or not, it is possible to style HTML in Safari using the value of ARIA property and state attributes—and this is actually the case for Opera, Firefox 3.5, and even Internet Explorer 8 as well.

• Perhaps most importantly, the two most widely used screen readers, Window-Eyes and JAWS, have solid support for ARIA in their most recent versions.

The demonstrated commitment of these developers to implementing ARIA indicates widespread support on the web. In addition, a number of very high-profile websites and applications including Google’s Google Reader feed reader and Gmail use ARIA extensively. Consequently, developers can feel confident that ARIA is a technology worth investing time and effort in.

Validation and ARIA

So how can we use ARIA in our markup today? We know that simply adding attributes that aren’t part of the HTML specification to our markup will make our documents invalid. There are several ways to use these features that will let our documents validate, though they can be a little more complicated than simply choosing a DOCTYPE.

It’s possible to use custom DTDs (document type definitions) that include the attributes of ARIA. At present there are no such reference DOCTYPEs for HTML or XHTML, though there have been calls for the W3C to provide them. The Paciello Group, a well known and respected accessibility consultancy, have an experimental HTML 4.01+ ARIA DTD (www.paciellogroup.com/blog/?p=107) that can be used with the W3C’s HTML validator.

The experimental HTML5 validator at www.validator.nu also validates ARIA and HTML5. It will give errors with non–HTML5 DOCTYPEs, but is a useful tool for ensuring ARIA is used correctly. It has limitations as to what aspects of ARIA it will test, one of which is a lack of recognition of “landmark” roles.

The emergence of ARIA raises a bigger question, however: is validation always an important goal? After all, despite ARIA’s tremendous potential value and solid browser support, without a good method of creating valid documents that incorporate ARIA, the technology falls at the validation hurdle. When it comes to the use of new web technologies, validation is a bit like driving while looking in the rearview mirror. Henri Sivonen, one of the more influential figures in the development of HTML5 (and the developer of the HTML5 validator) makes this observation:

[G]etting new features is much more important than validating against a legacy validation target. ARIA adds markup, so ARIA can’t validate against a legacy validation target such as XHTML 1.0 (without retroactively changing what XHTML 1.0 is). (wiki.codetalks.org/wiki/index.php/Web_2.0_Accessibility_with_ARIA_FAQ)

If validation is absolutely required because of internal or regulatory requirements, there are solutions. But if validation is essentially a quality assurance mechanism, it’s possible to intelligently use the output of HTML 4 or the HTML5 validators to check the quality of your ARIA-enabled markup, even if the document doesn’t strictly validate.

Common Accessibility Problems (and Solutions)

We’ll finish this chapter by addressing some of the most common accessibility problems, and ways of addressing them simply with HTML and CSS.

Links and Titles

Links are extensively used by screen readers and assistive devices to give users quick access to the contents of a page. While they only constitute a small percentage of the text on a page, they are a key way for many users to access a page’s content. The text of a link is an important guide to where a link will take a user. For optimum accessibility, link text should “clearly identify the target of each link” (WCAG 1), and avoid assumptions about users’ input devices revealed by use of terminology like “click here” as the link text. When several links on a page use the same text, they should all point to the same location.

The title attribute on link elements, although considered by many to add valuable accessibility information, can in fact be harmful: it can obscure other content in browsers that display title information as a tooltip, it isn’t accessible unless a mouse is used, or users of screen readers have their settings so that title values are read out. There is no consensus in the industry as to whether the title attribute should be used, but it should definitely not be the only way for users to identify a link’s destination.

Headings

Screen readers often use the headings on a page to create a “table of contents” to help users scan the page and jump to relevant areas. If you use heading elements as headings and use the heading order sensibly, you can make these screen-reader behaviors more usable. Don’t skip heading levels (from h2 to h4 for instance). The visual style of headings can always be changed by CSS, so there’s no need to skip a heading level.

alt text

Any non-textual content should have a textual alternative. With images, you can do this using the alt attribute. (A pedantic note from an old-timer: it’s not the alt “tag.”) Any alt content should be succinct, and although all img elements require an alt attribute in order for a page to validate, purely decorative images should have an empty string as the value of their alt attribute. Better still, purely decorative images (list-item bullets, for example, or decorative background images) should be included via CSS, not markup, which should be reserved for semantically useful content.

Color Contrast

The rather vague term color blindness leads to the common misconception that people who are color blind see the world in grayscale. This kind of vision impairment (“monochromasy”) is in fact extremely rare; the majority of people with color blindness see in color, but have difficulty distinguishing between certain colors that are easily distinguishable by people without color blindness.

Although it’s important that we avoid using only color to convey meaning (for example, using red as a warning, in the absence of additional shapes, text, or other information), there are other color-related accessibility concerns to consider. A lack of sufficient visual contrast between the text and its background is a commonly neglected problem. A text-background pair that appears “obviously” high contrast to someone without color blindness may be illegible to someone with color blindness or another visual deficiency.

Many tools will report whether a pair of colors has a sufficient contrast for legibility, but using these can be time consuming, since you must manually test each foreground and background color combination for a site. Tools like AccessColor from AccessKeys (www.accesskeys.org/tools/color-contrast.html) analyze an entire document by looking at the DOM and highlighting possible contrast problems. Most contrast-testing tools only work when text is set against a background color (not an image), however, and they don’t test dynamic effects like hovering, so they can’t provide a foolproof test of color contrast.

Tables

Tables present particular challenges for visually impaired users. The structure of a table, which may appear obvious to sighted users, can be confusing when read by a screen reader. HTML provides several elements and attributes to help screen readers read out the contents of tables more sensibly.

In addition to the standard td (table data) elements, tables may also have table header (th) elements, as we saw in Chapter 4. To make tables as accessible as possible, th elements should be used for the cells that are the headers of rows or columns.

caption and summary

The table caption element exists to provide a short description of the table, which is used both visually by a browser, and by screen readers. It’s recommended tables have a caption, which is marked up immediately after the opening tag of the table. Tables may only have a single caption.

In addition, the table element may have a summary attribute, which provides an overview of the contents of the table for users of screen readers. Sighted readers can also get a sense of the table and its contents at a glance; the summary attribute exists to help readers with visual disabilities do so as well. Unlike captions, summaries are not rendered by visual browsers—they are exclusively used by screen readers.

abbr and scope

Already we’ve given the browser a good deal of information that will make our tables more accessible. But particularly for complex tables, HTML has a number of under-utilized but helpful features that screen readers can use to help their users make more sense of data tables.

Because screen readers usually read each cell (including header cells) linearly, each header will be read many times, which may become time consuming and annoying. We can use the abbr attribute of the th element to define abbreviated text to be read in place of the full contents of the th element.

It’s not always clear from the structure of a table whether a th element is the header for a row or a column of cells. The scope attribute allows us to specify which cells the th element is the header of. In our case above, the headers are for columns, and so our markup would be:

For relatively simple tables, a screen reader can use the scope attribute to read out the header (or abbreviated header if we’ve added an abbr attribute) in front of the contents of a cell.

For example, in figure 6.1, the screen reader might read the highlighted cell as “design Font Embedding and Typography Mark Boulton.” But, as this example shows, this is far from the whole picture. What the reader really needs to hear is something along the lines of “10.45am–11.40am design Font Embedding and Typography Mark Boulton.” In essence, we need to associate more than one header with the cell. We can do this by adding an id to each header, and then using the headers attribute for td elements to associate th elements with a td element.

6.1 A sighted person can easily deduce that the font embedding session is in the design track at 10.45. For those using screen readers, it can be far from easy, unless we use the right markup.

While this additional information requires extra effort to mark up, the impact on accessibility for people using screen readers can be substantial. Like most development practices, when first encountered and used, these techniques may seem like a burden, but using appropriate attributes and elements soon becomes second nature.

Forms

You can directly and significantly improve the accessibility of your pages by marking up forms correctly. A few simple practices will greatly increase the usability of forms for people with various disabilities.

Form field labels provide absolutely vital information for users of screen readers. Although visual cues make it easy for those of us with good vision to determine what a field is for, unless form fields are explicitly and correctly associated with labels, users of screen readers may be unable to determine how a form works.

Some form elements—button elements, for example—have their own labels. For these elements, the value of the value attribute is the label for the element. When there is no implicit label, which is the case for most form elements, the label element should be used, and associated directly with the element it is the label for using the for attribute of the label. Here’s how we can ensure maximum accessibility for our labeled text input field:

Note that we’re also using the ARIA attribute aria-labelledby in the form element itself—the input element, in the preceding example—to give the browser the id of the element that labels the present element. So in our example, we have indicated that an element (the label element, appropriately enough) with the id of last-name-label provides the label for the input element whose id is last-name.

Sharp-eyed readers may note that aria-labelledby works just like the HTML 4 for attribute, but backward: with for, the labeling element identifies the labeled element by its id; with aria-labelledby, the labeled element identifies the labeling element by its id. Note too that labelledby, though not standard U.S. spelling, is correct in this instance.

When a label element cannot be used, WCAG 2 suggests that it is sufficient to use the title of the element as the label. For example, we’d need to use title for a search box in the toolbar of a page, where a label would take up more horizontal space than is available.

Grouping Field Elements

More complex forms may make more sense when related fields are grouped together with a heading for each group. HTML provides the fieldset and legend elements for precisely this purpose. A fieldset is simply a fieldset element that contains all of the related form elements. The first element of the fieldset should be its legend, which is similar to a caption for a table.

The techniques we’ve covered here address many of the most common accessibility difficulties that users face on the web. Implementing them is typically not onerous, and goes a long way to improving the experience of your sites by people who are most reliant on the web. It will also go a long way to addressing the legal and institutional obligations you or your organization may be required to meet.

The Wrap

In this chapter, we’ve taken a high-level overview of accessibility, including the underlying legal and ethical framework, existing W3C standards, and specific accessibility problems and solutions. Besides these points, what should you take away from this chapter? The most central concept is the idea that, rather than being a checklist of corrections to be made at the end of the development process, true accessibility arises from a holistic approach to web design and development—one that not only benefits users with disabilities, but all users. (The same techniques that improve accessibility often improve usability as a whole.)

The prominence of accessibility in web development has increased significantly in the last decade, due in large part to individual evangelists within the industry. There’s little doubt that legal frameworks and social expectations are all headed in the direction of greater accessibility to more people. Rather than worrying about the “stick” of legislation and legal action, think of the “carrots”: the opportunity to reach the many people with disabilities who visit your site, the built-in search-engine friendliness of accessible code, and the satisfaction you’ll derive from doing something to improve the online lives of so many others.