Pro HTML5 Accessibility: Building an Inclusive Web (2012)

C H A P T E R 1

Introduction to HTML5 Accessibility

In this chapter, I will introduce accessibility, define what it is, and discuss why you should be paying attention to reducing the barriers to access that might exist for many people in the systems you build. We will also look at HTML5 and examine its main differences from HTML 4—and you’ll see what this means for accessibility as well as how those differences will impact the way you build web sites and applications.

Introduction to HTML5: The New Wave

HTML5 is here. It is the new lingua franca for the Web. So what is it? HTML5 is the new version of HTML 4, XHTML1, and DOM Level 2 HTML. It has moved HTML from being a relatively simple document markup language to being a sophisticated platform for web applications with a host of new, rich application programming interfaces (APIs).

As with all major changes in life, the transition might not be smooth. Such a major shift that adds a host of new elements and attributes presents particular challenges for you as an author as well as, potentially, for the consumer.

HTML 4 was readily understood and offered features that could be used in imaginative ways. By leveraging these features in combination with other languages like Cascading Style Sheets (CSS) and JavaScript, developers could do things that were increasingly complex, pushing the models of user interaction.

With the advent of Web 2.0–type content such as AJAX, dynamic content updating, and more client-side processing, we saw a variety of terrific, sophisticated applications being developed out of what were often semantically limited markup languages.

This new wave of glossy widgets—and sometimes bizarre interaction models—often present many challenges to the user. If the user has a disability, the challenge is greater, because that user might not be able to access important widget functionality from the keyboard or content updates might be lost on the screen-reader user. Long before HTML5, many web designers started to really care about accessibility and look for ways to ensure their web sites and applications were usable by the widest audience. So grassroots movements like the Web Standards Project were born. An active and vibrant community arose that saw the challenges of improving the user experience and quality of design as a call to arms.

If you are reading this, chances are you are a web designer or developer and you would like to know more about HTML5 and how it relates to accessibility. So you’re in the right place. This book assumes you have a decent level of knowledge of HTML 4, as well as some CSS experience and maybe some JavaScript experience. It also assumes you’re keen to learn about developing robust web sites and applications by using HTML5.

If you’re not an expert CSS or JavaScript person and don’t even know much HTML, don’t worry! This book is designed to provide sufficient references to online materials and resources that will soon get you up to speed. The HTML5 spec is notoriously large (about 800 pages), so what this book tries to do is distill the parts that relate most to developing accessible web sites. This book (in tandem with some other more generic HTML5 resources) should help you come to terms with the game-changer that is HTML5, as well as accessibility.

In this book, I will attempt to share with you what I know about both—as a web designer and developer and as someone who has worked with people with disabilities for nearly 10 years. I am also a member of the HTML5 working group, where my input has had particular emphasis on accessibility and on trying to ensure (with many others) that the HTML5 specification will best serve the needs of the broadest range of users, including people with disabilities.

HTML5 vs. HTML 4

So what’s new in HTML5, and how does it differ from HTML 4? First, HTML5 is designed to do an awful lot more than just mark up text or be a hypertext markup language. (You are forgiven if you thought it was.) Second, many new APIs are now contained within the new specification that might not seem, at first glance, to belong in a document markup language at all.

These APIs are many and varied, and include Web Workers (an API for running scripts in the background independently of any user interface scripts), Web Storage (similar to HTTP session cookies, for storing structured data on the client side), and Web Sockets (for bidirectional communications with server-side processes). When you factor in native, “in the browser” support for video and audio via the <video> and <audio> elements—which signal a significant move away from browser plugin solutions like Flash, as well as the new 2D drawing API <canvas>—it’s obvious that HTML5 is far more than a mere document markup language and really is a quantum leap beyond the other earlier versions of HTML.

Note The added features are a mixed blessing. With these new language features, there will be more functionality but also more complexity both for you as an author and for your users. However, employing best practices in terms of user interface design and also in how you approach coding your projects will stand you in good stead. So while it might feel a little like you have to start all over again, I hope you will see that it doesn’t entirely have to be like that. You will just have more choice and, of course, learn a few things. I hope also that the good things you might know about making stuff accessible using a combination of HTML 4 and CSS/JavaScript will often still apply. Don’t be worried about keeping things simple—just using the right tool for the right job can get you very far.

HTML5 Syntax

In terms of syntax, HTML5 is a language that wears two hats. It can be written as both HTML and XML (also known as XHTML, which is an XML serialization of HTML—or put another way, an XML-like version of HTML that brings some of the rules of XML syntax to HTML).

Depending on your own requirements, you might need to serve more strictly well-formed XML-type documents to your users. Doing that will require the use of an XML parser, which is used to process XML documents. Alternatively, content comprised of HTML that is syntactically more lax HTML might suffice for your needs, in which case you can use an HTML parser. “More lax HTML” refers to code that might be a little sloppy but still works.

The HTML5 <!DOCTYPE>

In earlier versions of HTML and XHTML1, whether your documents were HTML or XHTML was defined primarily by the DOCTYPE (which was that kind of scary code in the header of your webpages that no one really knew what it did and that seemed arcane and pointless, although it was neither of these things). The DOCTYPE is really meant for machines to handle as a way of identifying the vocabulary that the document contents are meant to conform to.

In previous versions, you had the following DOCTYPES:

For HTML 4.01 Strict:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

For HTML 4.01 Transitional:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

or for XHTML 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

or XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

In HTML5, it is much simpler. Here is the new HTML5 DOCTYPE:

<!DOCTYPE html>

It’s kind of neat, and certainly easy to remember. There are other advantages, as well. For example, you’re no longer required to reference a DTD (Document Type Definition), as you were in previous versions of HTML, so it’s pretty elegant and will trigger Standards Mode in all newer browsers.

Some DOCTYPE History

Triggering Quirks Mode is a technique used by developers to ensure backward compatibility with older browsers. The need to do this came about because of the practical peculiarities of different browsers when rendering code, and poor or incomplete implementations of technical specifications like the W3C DOM.

Since different browser manufacturers choose to implement the specifications differently, developers were forced to leverage the various rendering modes that were triggered by the DTD in a page in order to see how the document would be parsed, testing their content in Standards Mode, Almost Standards Mode, and Quirks Mode.

I hope now with HTML5 we are getting closer to the “author once then publish to many devices/platforms” model. If you don’t remember all this, consider yourself lucky – it wasn’t fun and made web development torturous. If you do remember all this, have a stiff drink. If you wish to read up on it, visit http://en.wikipedia.org/wiki/Quirks_mode.

Note In XHTML, no DOCTYPE is actually required, but you might need to use one when you have, for example, what’s called a polyglot document (which is a hybrid document that can be served as both XHTML or HTML) or you need to declare entity references (symbols, mathematical symbols, language characters, so forth) for use within the document.

It makes sense when you think about it. If you and I are at a party and I say, “The veggie samosas are on the table, beside the woman with the great figure,” you would know what I mean. For a browser, the use of the word table and figure mean totally different things; therefore, a way to explain to the browser what language is being used in a document that it must parse is vital in order for the software to know what to do with its contents.

If a load of browsers were at a party that line would mean something totally different (not that browsers eat veggie samosas) than it would in the context of our daily lives.

Note It’s important to understand that with previous versions of HTML developers often struggled with whether to use “strict” or “transitional,” and confusion as to how the browser would treat content, given a specific DOCTYPE, was common. For a very interesting overview of the whole history of DOCTYPES, parsing rules, and the MIME type (more on that later), I recommend reading Ian Hickson’s article, “Sending XHMTL as text/html Considered Harmful,” which explains some history, how these things came to be, and some best practices. You can find it athttp://hixie.ch/advocacy/xhtml.

HTML5 and XHTML as text/html (It’s a MIME Field)

Now, in HTML5, how your content is parsed is dependent more on the choice of the media type than the DOCTYPE.

This means that XML-type documents need to be given the XML media type, such as application/xhtml+xml or application/xml. By contrast, if you’re using HTML syntax, you serve the document as text/html. This is often done in the HTTP – Content type Header, which takes the following form:

This tag appears inside the header of your document. (If you have server-side coding chops, you can use Content Negotiation. For more details, see www.w3.org/2003/01/xhtml-mimetype/content-negotiation.)

Listing 1-1 is an example document that conforms to the HTML syntax.

Listing 1-1. HTML Syntax

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>HTML Syntax Document</title>
</head>
<body>
<p>This doc is HTML.</p>
</body>
</html>

The other syntax that can be used for HTML5 is XML. Some things to note are the following:

· All documents with a text/html media type (such as older languages prior to HTML5 or documents having an XHTML1 DOCTYPE) will be parsed using the algorithm as defined by the current HTML spec.

· XHTML must no longer be served as text/html, and it must use application/xhtml+xml or application/xml.

· HTML documents must be served as text/html.

· For most of this book, we will be dealing with HTML and the content type text/html, which is included in the document header as shown earlier.

· <meta charset="UTF-8"> can now be used to specify the UTF-8 encoding. This replaces the need for the longer <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">, although that syntax is still allowed.

What Syntax Should I Use?

You should be able to make the call yourself about what way you wish to author, as this should already be clear to you in terms of your previous authoring practice. You might, however, currently be asking, “What syntax do I use?” The chances are that if you’re asking this question you can stick with serving your content as HTML using the text/html mime type because you don’t have the requirements beforehand in your project to use more strict XML-type syntax.

XML follows simple rules such as requiring all content to be case sensitive, requiring you to close all tags, and to follow other such guidelines, whereas HTML content is more lax, it is not case sensitive, unclosed tags won’t break your page, and so on.

Note If an incorrect or badly authored XML document is parsed by the more strict XML parser that doesn’t match the rules of well-formedness, the document might not display—and that’s a critical error which you probably don’t want.

If the same rules were applied for all HTML documents on the Web (whether they are earlier versions of HTML or the latest), the Web would break, nothing would work! So, while HTML5 needs to have rules for dealing with both kinds of content (which it does), it must also treat badly formed HTML (or tag soup as it came to be known) in a way that can still be usable.

New Elements

Now we will look at some of the new elements that have been introduced in the HTML5 spec, as well as what they are for. There are quite a lot, and one of the tricky things is to determine where and when to use them. This is made somewhat easier by the fact that most of the new elements “do what they say on the tin.” To use most elements, you won’t have to think too deeply. It might be a little less clear what some others are for or when you would use them.

Note Don’t be worried about adding HTML5 elements to your projects right now, even if you are not totally sure about support for an element or whether it will work 100 percent. When a new element is parsed by a browser or piece of assistive technology that it just doesn’t understand, it is dealt with as plain text—and generally will not break anything.

Some HTML5 elements might not actually render or display in the browser (primarily because they might not be understood by it yet, although support is rapidly improving). It’s also possible that while they might display visually, their semantics might be misunderstood or ignored by assistive technology. When this happens, you don’t need to worry about them triggering any unusual behavior most of the time. However, if there is some strange behavior that gets triggered in the browser or some weird rendering quirk (anyone involved in web development for more than the past five years should be familiar with those quirks from the joy that was CSS coding), you’ve found a bug!

The best way to deal with bugs is to report them to the W3C and/or to the browser manufacturer. These nuggets of information really can help to make things better and improve future versions of software.

More than likely, you will find that someone, somewhere has found the bug and a group of developers have worked out a fix or hack. Hacks are a mixed blessing. Ideally, we wouldn’t have to do them, but the world isn’t a simple place, is it?

While we will go into much of the following in later chapters, here is an overview of some of the new elements that have been introduced in HTML5 for better structure:

· <section> represents a generic document or application section. It can be used together with the h1, h2, h3, h4, h5, and h6 elements to indicate the document structure.

· <article> represents an independent piece of content of a document, such as a blog entry or newspaper article.

· <aside> represents a piece of content that is only slightly related to the rest of the page.

· <hgroup> represents the header of a section.

· <header> represents a group of introductory or navigational aids.

· <footer> represents a footer for a section and can contain information about the author, copyright information, and other such details.

· <nav> represents a section of the document intended for navigation.

· <figure> represents a piece of self-contained flow content, typically referenced as a single unit from the main flow of the document, as shown here:

<figure>
<video src="example.webm" controls></video>
<figcaption>Example</figcaption>
</figure>

· <figcaption> can be used as caption for an image or other graphical content (it is optional), as shown in the preceding code example.

Then there are several other new elements:

· <video> and <audio> are for multimedia content. Both provide an API so that application authors can script their own user interface, but there is also a way to trigger a user interface provided by the user agent. source elements are used together with these elements if multiple streams of different types are available.

· <track> provides text tracks for the video element.

· <embed> is used for plugin content.

· <mark> represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context.

· <progress> represents the completion of a task, such as downloading or performing a series of bandwidth expensive operations. This information can be very useful for people on limited broadband connections or for those using a dial-up service.

· <meter> represents a measurement, such as disk usage.

· <time> represents a date and/or time.

· <ruby>, <rt>, and <rp> allow for marking up ruby (an Open Source Object Orientated programming language) annotations.

· <bdi> represents a span of text that is to be isolated from its surroundings for the purposes of bidirectional text formatting.

· <wbr> represents a line-break opportunity. Word break can be used within a string.

· <canvas> is used for rendering dynamic bitmap graphics on the fly, such as graphs or games.

· <command> represents a command the user can invoke.

· <details> represents additional information or controls the user can obtain on demand. The summary element provides its summary, legend, or caption.

· <keygen> relates to more secure form creation and represents a control for generating a key pair, where a private key or code is stored on the client side (locally) and the public key is sent to a server (remotely).

· <output> represents some type of output, such as from a calculation done through scripting.

· The <input> element provides a field for the user to input data. In HTML5, it has new types and attributes. You might have some predefined input that you require from the user that you can define as option values (such as a Guitar type, as shown in the next example). We’ll look at this in more detail in Chapter 8 on HTML5 forms.

· The <input> element has a type attribute, which now has the following new values:

· tel

· search

· url

· email

· datetime

· date

· month

· week

· time

· datetime-local

· number

· range

· color

These new input types are provided to the user interface via the browser. They provide better, more sophisticated methods of form validation that can be done on the client side without calls to the server. There are also a host of new attributes that we’ll look at as they arise throughout the book.

Also in HTML5, several attributes from HTML 4 now apply to all elements. These are called global attributes and include the following: accesskey, class, dir, id, lang, style, tabindex, and title.

There are also several new global attributes:

· The contenteditable attribute indicates that the element is an editable area. The user can change the contents of the element and manipulate the markup.

· The contextmenu attribute can be used to point to a context menu provided by the author.

· The data-* collection of author-defined attributes allows authors to define any attribute they want as long as they prefix it with data- to avoid clashes with future versions of HTML. The only requirement on these attributes is that they are not used for user agent extensions.

· The draggable and dropzone attributes can be used together with the new drag-and-drop API.

· The hidden attribute indicates that an element is not yet, or is no longer, relevant.

· The role and aria-* collection attributes can be used to instruct assistive technology. There will be more about WAI-ARIA in Chapter 3, “JavaScript Isn’t a Dirty Word, and ARIA Isn’t Just Beautiful Music,” where we will look at what it is, how to add it to your projects, and why it’s important for accessibility.

· The spellcheck attribute allows for hinting whether content can be checked for spelling or not.¹

HTML5: Accessibility and Feature Detection

So, that was an introduction to some of the new features of the HTML5 language. As I mentioned earlier, in later chapters we will be looking at how these new features relate to accessibility and what you can do with them to build accessible interfaces, as well as some of the challenges that await you.

The bad news is that many of the new HTML5 features are only starting to be supported by both browsers and assistive technology. From an accessibility perspective, this means you might have to be creative to make sure your content actually works, rather than taking an “in the spec it says do it this way, so that means it’s supported” approach. The cookie doesn’t crumble that way, unfortunately.

What’s more, the specification doesn’t entirely define the user experience. (And it could be reasonably argued that this is out of scope for the spec; however, I am inclined to side the other way.) So care must be taken to apply code in a practical way that can support the greatest range of users. And that’s why you’re reading this book, right?

The good news is that support for HTML5 is improving all the time, for both browsers and assistive technology (AT), so the future is bright. You might find that some of the elements or attributes you want to use are poorly supported in either the browser or by the assistive technology (and sometimes both), and I am very aware of this as I write the book. Where possible, I will try to illustrate how you can use HTML5 in a way that can be supported by older markup also, or by other accessibility languages like WAI-ARIA (which I’ll say more about later).

__________

Note At time of this writing, many of the big players in the browser market have really good HTML5 support. It is often the AT that doesn’t.

This book pays particular attention to backward compatibility in its general tone and tries to help you support what is known as legacy user agents, or older browsers and AT. Approaching the markup and design of your web content in a way that supports both the newer user agents that understand it, as well as those that don’t (by giving them something to get their semantic teeth into), is the bedrock of progressive enhancement, which is the more enlightened approach to design.

Note Throughout this book, I will often suggest that you borrow from other more accessibility-focused languages, like WAI-ARIA, because this is a really useful way of bridging the semantic accessibility gap in your projects. WAI-ARIA is now also officially a part of the HTML5 spec anyway, and it’s a perfect tool to use to describe a widget’s role, its state, or other properties to AT. It also has improving support in both the browser and AT.

There are also interesting techniques that can be used in HTML5, such as feature detection. This allows you, as an author, to query the user agent that your web content is being served to, in order to see if a given browser has support for specific features of HTML5 and then serve that browser that content—or don’t serve it if the browser does not provide support. If that is all a little scary for you, there are tools such as Modernizr that can be used to do much of this for you.

Note Modernizr is an open-source JavaScript library that uses media queries and scripted feature detection. It can be a useful tool in building your HTML5 pages. You can find out more at http://www.modernizr.com.

Now let’s look at some background information about accessibility—what it is and why you need to make it part of your design.

Defining Accessibility

There are several definitions of accessibility. The International Standards Organization (ISO) defines accessibility this way:

“The usability of a product, service, environment or facility by people with the widest range of capabilities.”

(ISO TC 16071, 2003)

Applying this definition to the Web ensures the interfaces that you design can be used by the widest possible audience, and therefore ensures there are no users who are left out. This sounds like a lofty ideal, and it might even seem daunting (and this is understandable), but don’t worry. It really is amazing what you can do with HTML5, CSS, and JavaScript when you combine them the right way.

The W3C, in its “Introduction to Web Accessibility,” defines accessibility as this:

“Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.”

(WAI Introduction to Accessibility, 2010)

You will notice that the first definition does not mention blind users or other people with disabilities at all, yet it talks about general usability (which I’ll discuss in more detail later). I prefer the second definition presented, because I think of accessibility as being “about people with disabilities.” This helps me to theoretically understand the group I am trying to serve in a clear way, and it also removes some ambiguity in the definition. I find that if something is defined in too broad a way or is vague, it can be difficult to get a bead on what to do or where to start. By narrowing the definition, you have a more clearly defined point of reference.

Technically, accessibility can be defined as a subset of usability and thought of as a child of another discipline. Then again, usability can be understood as a child of Human Computer Interaction (HCI), which used to be called “Human Factors Engineering,” more commonly known asergonomics.

Accessibility: From Theory to Practice

Leaving the pros and cons of various definitions aside, in practice it is very important as a designer to try to understand the diverse needs of your audience. These needs vary greatly, and they cover a broad range of people of varying technical knowledge, manual-dexterity abilities, visual acuity, cognitive capacity, and speed.

So how can the average designer account for all this effectively? Are there ways to accomplish this goal that are accessible (to the designer, without taking on a degree in the area!) that will help you find your way through the maze of sometimes arcane or esoteric recommendations? This pursuit can be very daunting, but the answer is a resounding “Yes!”

This book aims to help you critically assess not only the design decisions you make, but also the sometimes contradictory advice you get from various guidelines and best practices so that you can be sure it is suitable for your needs. What’s more, don’t make the assumption that because “The spec says x” that x must automatically be true or that x even works at all. This warning is even more pertinent when it comes to accessibility.

Many HTML5 elements and attributes either are not, or will not, be supported by various browsers and/or assistive technologies, such as screen readers that are used by people with disabilities. Although the specification might clearly outline how a particular feature is to be implemented in the real world, it is often left to the vendor (or manufacturer) of a particular user agent (which is a catch all term for a browser, or even piece of AT) how to actually implement the spec. So this does affect the user experience in a big way. If you think back to the “browser wars,” when there was no standard way for rendering different elements/attributes and when CSS had to be tweaked according to what devices it was being served to, you can see what I mean.

It will be the same with HTML5, and this book aims to practically show you how to future-proof your web content (regardless of what level of support is currently available for different HTML5 elements) in a way that is also backward compatible, which pretty much means that you need to ensure that it will work with older browsers and AT. Doing this successfully will sometimes mean playing loose with the rules. For example, when it comes to validation you might have to live with a few big red X’s when the validator parses your content and you have added some specific accessibility markup, such as WAI-ARIA (which I’ll say much more about later), to build an accessible JavaScript widget. However, the validator parsing rules often don’t make proper provisions for these kind of documents, so you get errors. But we can’t always have it every which way—such is life. If you are more concerned with building accessible stuff that really works, read on. But be warned: you might have to learn to think beyond the validator!

Later in the book, when we look at user-centered design, you’ll see the benefits of really connecting with your users and how to use alternative user-evaluation methods and techniques, such as user testing, which can really show you what works and what doesn’t work in your design.

User testing is a fantastic way to help you connect with your users and get a practical feel for the rights and wrongs of design. Implementing user testing is also a remarkable way of bridging the gap between you, the designer, and your end users. It also acts as a powerful way of moving from a theoretical understanding to a practical understanding of how design decisions impact the user.

User testing can be expensive, however, or just not practical. So we’ll also look at ways you can do quick and dirty guerilla testing and some simulation techniques that might help you get a feel for the user experience that people with disabilities encounter. You might also benefit from the advice I give later on regarding testing yourself with a screen reader. This process can be a mixed blessing, and it needs to be approached with caution. This is because you need to be confident that any problems you experience when testing a web site with a screen reader are actually the result of an accessibility problem with the site, and not you having difficulties getting to grips with the AT!

This is a very common problem, but I aim to show you how to up your game when it comes to testing with common screen-reading software like JAWS or VoiceOver. I’ll discuss how to approach the tests, explain what’s going on when you are using the screen reader, and describe some common errors to avoid.

Understanding Accessibility

Good, accessible web sites are genuinely a natural by-product of good design. Good design comes from understanding some core things:

· What you are designing for and what the purpose of your site is

· Your audience’s needs

· What visitors really wish to do when using your site

As stated previously, accessibility can at first seem abstract or esoteric. Many developers can find it difficult to grasp it fully as a practical discipline. Many people just don’t get accessibility.

There are some aspects of accessibility that are initially easier to understand than others, but gradually, as their knowledge of best practices deepens, developers can quickly grasp that accessibility is rather practical.

Accessibility is an ever-evolving line, a continuum. However, for users of AT there are some core issues for each user group that don’t really change—even if the technology does. For example, blind users need to be able to access equivalent content that describes to them what a particular image is all about, people with limited physical mobility really appreciate not having a lot of useless links to tab through, and so on.

Legislation

Depending on the country you live in, there will be different legislative requirements you might need to consider when building your web site. The degree to which legislation affects you depends on the purpose of your web site, whether you intend to do business with the federal government, or whether you are designing and developing for a public sector agency.

Understanding the law and how it relates to your project is very important. The following is a brief overview of legislation in different domains, covering the USA first and then the UK. Many thanks to Jared Smith of WebAIM from where much of the following is drawn from.

Rehabilitation Act

In the United States, the Rehabilitation Act of 1973 was the first major legislative effort to secure an equal playing field for individuals with disabilities. This legislation provides a wide range of services for persons with physical and cognitive disabilities. The Rehabilitation Act has been amended twice since its inception, once in 1993 and again in 1998. Two sections within the Rehabilitation Act, as amended, have an impact on accessible web design: sections 504 and 508.

Section 504

Section 504 of the Rehabilitation Act is a civil rights law. It was the first civil rights legislation in the United States designed to protect individuals with disabilities from discrimination based on their disability status. The nondiscrimination requirements of the law apply to employers and organizations that receive federal financial assistance.

Section 504, 29 U.S.C.§794, states the following:

“No otherwise qualified individual with a disability in the United States... shall, solely by reason of her or his disability, be excluded from participation in, be denied the benefits of, or be subjected to discrimination under any program or activity receiving Federal financial assistance.”

Therefore, any programs receiving federal funds cannot discriminate against those with disabilities based on their disability status. All government agencies, federally-funded projects, K-12 schools, and postsecondary entities (state colleges, universities, and vocational training schools) fall into this category.

Section 508

The Reauthorized Rehabilitation Act of 1998 included amendments to Section 508, which you can access at http://webaim.org/articles/laws/usa/rehab. This section bars the federal government from procuring electronic and information technology (E&IT) goods and services that are not fully accessible to those with disabilities. This includes the services of web design because the Internet is specifically mentioned.

Influence of Section 508

Why is Section 508 such a big deal? Although it’s limited to federal agencies, Section 508 is an extremely influential piece of legislation. There are at least four reasons why this is so.

Section 508 provided the first-ever US federal accessibility standard for the Internet. The Web Content Accessibility Guidelines existed prior to this; however, these guidelines created by the Web Accessibility Initiative (WAI) were not intended to be written as standards. Plus, these guidelines came from a voluntary international body with no regulatory power.

This section provides compliance language that can be monitored at a distance. As stated earlier, guidelines did exist, but not in statutory language. Section 508 outlines binding, enforceable standards that must be adhered to in order for E&IT products to be accessible to persons with disabilities. A list of the Section 508 standards that apply to web accessibility is provided in the WebAIM Section 508 Checklist.

State governments might be held accountable for complying with Section 508. All states receive funding under the Assistive Technology Act of 1998. To gain access to this funding, each state must assure the federal government it will implement all conditions of Section 508 within their state entities (including institutes of higher education). Many states (for example, Arizona, Nebraska, and Wisconsin) have codified Section 508 to be state law, which requires state institutions to comply with these requirements.

Businesses must comply with Section 508 when supplying E&IT goods and services to the federal government. The influence of web accessibility on business and industry is more significant when the demands of a client, or potential client, like the US federal government must be met.

Section 508 Enforcement

The US Department of Justice Office of Civil Rights is charged with enforcing Section 508. When complaints arise, members of the public, students, and employees with disabilities can do the following:

· File an administrative complaint with agencies they believe to be in violation of Section 508.

· File a private lawsuit in federal district court.

· File a formal complaint through the US Department of Justice Office of Civil Rights.

The Office of the Attorney General is required to evaluate how well the government is conforming to Section 508. It is also required to provide updated reports to the President and Congress on both the accessibility of federal electronic and information technology to people with disabilities and the resolution of Section 508 complaints filed against federal agencies. The first such report was given in August 2001, and others have been given every two years thereafter.

Voluntary Product Accessibility Template

Voluntary Product Accessibility Template (VPAT) provides the details of how you comply with Section 508. It is a way of stating (up front) how accessible your product or service is. This can help with the procurement process because federal agencies can get an overview of how well your site or product performs compared to others.

Note For more information on VPATs and how to use them, see www.evengrounds.com/articles/creating-an-effective-vpat.

Other Relevant Legislation

While compliance with Section 508 is the main focus for most federal web projects, there are other acts to consider that have a bearing (while not explicitly referring to the Internet).

Americans with Disabilities Act

The Americans with Disabilities Act (ADA), passed in 1990 in the US, is civil rights legislation governed by the Department of Justice. The goal of this law is to make sure that people with disabilities can have an equal opportunity to participate in programs, services, and activities. Note that the ADA does not deal directly with the accessibility of the Internet. This might be because the Internet was just emerging as a widespread tool around the same time as the passage of the ADA. There are, however, two major sections in the ADA that might apply to web accessibility:

· Title II, which states that communications with persons with disabilities must be “as effective as communications with others” [28 C.F.R. ss 35.160 (a)]

· Title III, which deals with public accommodation of people with disabilities

Individuals with Disabilities Education Act

The Individuals with Disabilities Education Act (IDEA), as amended in 1997 in the US, provides for a “free appropriate public education,” from preschool through high school, for all children with disabilities.

The IDEA relates to the Web in the following ways:

· The Internet is being used to a greater degree each year in the K-12 school systems. In fact, it is being used in two distinct ways:

· Teachers use it to provide students with a general education curriculum in areas like history, science, English, or math. Students can explore materials and information, conduct research, engage in activities, and even take tests online.

· An education goal found in most US states is that students will learn to use the Internet. Therefore, this becomes a curriculum in its own right.

· Another relevant piece of legislation is Section 255 of the Telecommunications Act of 1996, which “requires manufacturers of telecommunications equipment and customer premises equipment to ensure that the equipment is designed, developed, and fabricated to be accessible to and usable by individuals with disabilities.”

Disability Discrimination Act 1995

In the UK, the Disability Discrimination Act (DDA) was introduced to end discrimination against disabled people and give them new rights in the areas of employment, access to goods and services, and buying or renting land or property.

There are some provisions in the Act (Part III) that arguably apply to web sites and have been in force since 1 October 1999.

However, the original Disability Discrimination Act 1995 was limited and missed some important areas, such as education. This meant that universities did not have to ensure that their educational services were accessible. This was dealt with by the passing of the Special Educational Needs and Disability Act 2001.

Special Educational Needs and Disability Act 2001

The Special Educational Needs and Disability Act 2001 (SENDA) was introduced as an amendment to the Disability Discrimination Act 1995 (DDA).

SENDA introduces provisions for people with disabilities in education in England, Wales, and Scotland. It aims for “comprehensive enforceable civil rights” for people with disabilities at school in England, Scotland, and Wales. It has major implications for further-education institutions, for the way the curriculum is delivered, and for the way students are supported.

PAS78, the DDA, and the Equality Act 2010

A very useful document for procurers of accessible web sites in the UK is PAS78. This publication provides guidance to organizations regarding how to commission an accessible web site from a design agency. It describes what is expected from web sites to comply with the UK Disability Discrimination Act 1995 (DDA), making web sites accessible to and usable by disabled people. In 2010, the DDA was superseded by the Equality Act. You can find more detail at the following sites:

· PAS78: www.equalityhumanrights.com/footer/accessibility-statement/general-web-accessibility-guidance

· The Equality Act 2010: www.legislation.gov.uk/ukpga/2010/15/contents

European Legislation

There are many individual pieces of legislation for each European Union (EU) member state, but there are also some overarching pieces of EU-wide legislation that relate to the Web and e-Inclusion.

Note The term e-Inclusion is the idea that no one should be left behind in enjoying the benefits of information and communication technologies (ICT). According to the European Commission e-Inclusion means “both inclusive ICT and the use of ICT to achieve wider inclusion objectives.”² It focuses on participation of all individuals and communities in all aspects of the information society. e-Inclusion policy, therefore, aims at reducing gaps in ICT usage and promoting the use of ICT to overcome exclusion, and improve economic performance, employment opportunities, quality of life, social participation, and cohesion.”

EU Charter of Fundamental Rights

The EU Charter of Fundamental Rights makes reference to people who are disabled:

· Article 21 prohibits discrimination based on grounds of disability, among other things.

· Article 26 provides explicit recognition of the rights of persons with disabilities and the need to ensure their independence, social and occupational integration, and participation in the life of the community.

i2010: A European Information Society

i2010 was the EU policy framework for the information society and media (2005-2009). It promoted the positive contribution that information and communication technologies (ICT) can make to the economy, society, and personal quality of life. The strategy is now coming to an end and is going to be followed by a new initiative—the Digital Agenda for Europe. For more information, see http://ec.europa.eu/information_society/digital-agenda/local/index_en.htm.

eEurope 2005

Before that, the eEurope 2005 Action Plan was launched at the Seville European Council in June 2002 and endorsed by the Council of Ministers in the eEurope Resolution of January 2003. It aims to develop modern public services and a dynamic environment for e-business through widespread availability of broadband access at competitive prices and a secure information infrastructure. This was preceded by eEurope 2002.

__________

² http://ec.europa.eu/information_society/activities/einclusion/index_en.htm

Note OK, scared? Well don’t be. This is all included here just to paint a picture of how accessibility is taken seriously. Yes, the degree to which it is varies in different countries, but there is an imperative. So you should feel motivated to do the right thing.

The good news is that even if you don’t totally get there with an “all-singing, all-dancing, full-on accessibility in-your-face” web site, making a sincere effort with your projects (in my experience) means an awful lot to the people with disabilities who use it.

It’s when people feel they are being actively discriminated against and that an organization just doesn’t care that there can be trouble. Actually, an “Accessibility” statement on a web site is really an “Inaccessibility” statement—and this makes sense if you define the scope of what you have done, or not done, and the work that is in progress. If you are up front about this kind of thing, it can certainly contribute to openness, transparency, and general good will—which is always a good thing.

Dealing with Change and Diversity

In many ways, the discipline of accessibility encompasses our ability, as designers, to deal with change and develop designs that can accommodate diversity in a positive way. There are natural changes that many of us will go through, such as failing sight and other physical and mental changes, as we get older. Therefore, our ability to perform certain tasks and the equipment we need may also change. Really understanding accessibility involves expanding our ability to deal with these changes.

The success of designers’ efforts often depends on how well they can accommodate diverse user requirements. Using new tools, languages, and development methods is really just a test of our ability to do that, and the advent of HTML5 is no different. If as a developer you have some previous experience with building accessible interfaces, the hard-won knowledge you have gained will benefit you. You don’t have to re-invent the wheel or start from some kind of “year zero” when you develop with HTML5. You might have to rethink your approaches to some kinds of content, because there have been some game-changers, but mainly, you will be able to nicely build on what you have learned previously.

The reality is that even though the languages and development methods that are used will often change rapidly, the needs of people with disabilities are pretty constant. This book focuses on some of the core aspects of designing for people with disabilities, which will hopefully simplify and enhance your understanding of the process.

What Are the Benefits of Accessibility?

There are some substantial benefits of accessible web design and development:

· It makes good business sense: Building accessible web sites can actually increase revenue for a business by ensuring that no one is excluded from its web site. There are some well-documented case studies that outline the business benefits of accessibility, such as the ones experienced by the following companies:

· Legal & General Group: Doubled visitor numbers, cut maintenance costs by two-thirds, and increased natural search traffic by 50 percent.

· Tesco: Spent 35 thousand GBP to build its web site, and had 13 million GBP per year in resultant revenue.

· CNET: Experienced a 30 percent increase in traffic from Google after it started providing transcripts. “We saw a significant increase in SEO referrals when we launched an HTML version of our site, the major component of which was our transcripts,” said Justin Eckhouse of CNET. (W3C Business Case Examples, 2009)

These benefits can be generally categorized as follows:

· Social Factors: Increased web accessibility provides equal opportunities for people with disabilities by removing barriers to communication and interaction.

· Technical Factors: Increased Web accessibility improves interoperability, and quality, and reduces site development and maintenance time and server load. It also helps to ensure that content is enabled on different configurations, and that developers are prepared for advanced web technologies.

· Financial Factors: Greater accessibility improves search engine optimization (SEO)and enhances direct cost savings due to easier maintenance etc.

· Legal and Policy Factors: Increased Web accessibility addresses requirements for Web accessibility from governments and other organizations in the form of laws, policies, regulations, and standards.

· Better design: Graphic designers often design for themselves. This is not always the case, but it is often true. As a result the Web is littered with sites that use tiny text that can’t be resized, illegible fonts, and bad color contrast. This often renders the site content unreadable to many. (WAI Business Case for Accessibility, 2010)

Note A good design principle is that “form should follow function.” This is a simple but effective rule of thumb that is unfortunately often ignored or just forgotten. As you progress with this book I hope that you will start to see that what you need to do to develop accessible interfaces really boils down to good design and coding practice. Accessibility is very practical and comes down to well-formed code, good User Interface design, solid Information Architecture, Human and Accessible Form Validation, and Error recovery. And the good news is all of this good stuff isn’t just of benefit for people with disabilities, but for everyone.

Accessibility Should Enhance Your Design—Not Destroy It

In practice, accessibility brings some important fundamental design issues back into sharp focus for designers. This is a good thing. We often see shiny new things being built on the Web, and then people like me come along, look more closely, and see that it just doesn’t work from an accessibility perspective. Then we have to be ones who say, “Hang on a minute.” So the perception is that the accessibility community is anti-progress or anti-design.

This isn’t the case, and no, we don’t want to ruin the party. We just know a bit about what works and what doesn’t. The Web is full of inaccessible stuff. In fact, the Web is inherently broken, and much of it shouldn’t work, but does, which is pretty amazing in itself.

Let’s look at how accessibility can limit a project in a positive way. Consider the following:

· To be accessible means that the designer must carefully consider how he or she presents content visually (in terms of clear design and color contrast) as well as how the underlying semantic structure of a web site is geared toward people with disabilities, or how a complex dynamic control can be used by someone with a disability. The effect of these “constraints” is that the designer must ideally use only whatever development techniques, elements, or attributes are suitable for the task at hand—the right tool for the right job. This approach is very important when developing HTML5 web content (as shall be demonstrated later when we look at new elements like <canvas>).

So accessibility is not anti-design, but merely a challenge. In reality, it helps to ground your designs in best practice across the board, and therefore brings extra benefits such as more future-proof, interoperable applications and web sites.

WCAG 2.0 and HTML5

The Web Content Accessibility Guidelines (WCAG 2.0) has been very carefully designed to be technologically agnostic, and I trust you will see the common sense in them when you are building your web sites and applications. Building accessible stuff that works is a very nuanced area. As I mentioned previously, you will have to balance real-world application of both the code and these guidelines in a way that is practical. Accessibility is not theoretical, mystical, or ethereal.

The needs of people with disabilities are very real and these guidelines are just that—guidelines and not a standard. They are meant to be informative and instructive, with the net result being that you have more accessible and usable interfaces.

Note Currently, there aren’t a lot (or any) HTML5 test cases for WCAG 2.0. However, as I write, there are efforts to develop guidance and test suites for accessible and WCAG 2.0–conformant HTML5, and there will be more available as time goes on. So keep an eye onwww.w3.org/WAI/GL.

WCAG is primarily intended for the following:

· Web content developers (page authors, site designers, and other such professionals)

· Web authoring tool developers

· Web accessibility evaluation tool developers

· Others who want or need a technical standard for Web accessibility

WCAG and related resources are also intended to meet the needs of many different audiences, including people who are new to Web accessibility, policy makers, managers, and others. WCAG 1.0 had various priority checkpoints; WCAG 2.0 has success criteria. While WCAG 1.0 was organized around a set of guidelines, WCAG 2.0 is organized around four simple principles, which form the acronym POUR.

· Principle 1: Content must be Perceivable (P). This principle refers to all content, including multimedia, video, and audio:

· Provide a text alternative for all non-text content.

· Provide synchronized alternatives for multimedia (such as captioned video, audio descriptions, and so forth)

· Information and structure must be separate from presentation.

· Make it easy to distinguish foreground information from the background (for example, have good color contrast).

· Principle 2: Interface elements must be Operable (O):

· All functionality must be operable via the keyboard.

· Users must be able to control limits on their reading or interaction.

· Users must be able to avoid content that can cause seizures due to photosensitivity.

· Provide mechanisms for users to find content, orientate themselves, and navigate through it.

· Help users avoid mistakes, and make it easier to correct mistakes when they do occur.

· Principle 3: Content and controls must be Understandable (U):

· Make text content readable and understandable.

· Make the placement and functionality of content predictable.

· Principle 4: Content should be robust enough to work with current and future technologies (R):

· Support compatibility with current and future user agents.

· Ensure that content is accessible, or provide accessible alternatives (from WAI Introduction to WCAG, 2010).

I hope you can see that much of the advice is quite practical. In reality, it is often a case of “It doesn’t matter how you get there as long as certain criteria are met,” such as those just outlined.

The Challenge of HTML5 Accessibility

As you can see, there are a lot of changes afoot! As with any new major change, it may not all be smooth sailing. Dealing with this change can be difficult because the goalposts are actually moving. This is partially because HTML5 is itself still in draft. However, it has reached its first LC (or Last Call) for comments. As such, it is approaching a steady state.

This presents some challenges when writing about HTML5 because its support in browsers and AT is only starting to come on-stream. However, as the browsers implement them, so then the AT technologies often follow. This happens because vendors can then see that certain features are gaining use, and they will therefore make choices about what they support and how this will impact the user experience. Ultimately, the good news is that the toolkit has been dramatically expanded with HTML5, though you may often be faced with the problem of too much choice when it comes to approaching how to mark up your web projects.

As I touched on earlier, the semantic feast that follows from HTML 4 is pretty amazing.

Conclusion

In this chapter, I introduced you to the wonderful world of accessible web design and gave you a flavor of some of the challenges that lie ahead. There will be ups and downs, but it really can be fun. You won’t always get things right, but trying to goes a long way. In the next chapter, we will look at disability in more detail as well as some of the more commonly used assistive technologies.