Accessibility in HTML5

This is a summary of my session on HTML5 accessibility at Accessibility Camp Toronto (I didn’t use slides for my talk, so you’re getting this instead).

Accessibility is not a niche area of web design: everybody who works on the web needs to be interested in accessibility. You should try to make your websites as accessible as possible. For some of you it’s a legal obligation, but for everyone else it’s just the right thing to do.

What Is Accessibility

Accessibility for the web means making sure that our web pages and applications are available to everyone, including people with disabilities. Many but not all users with disabilities use assistive devices or software to browse the web. This includes on mobile devices as well as regular desktop computers.

People who are blind use assistive technology such as screen reader software (which reads the contents of the page out loud), and less frequently a braille display that converts text on the screen to braille.

For those who are hearing impaired, most of the web is accessible, except for video and audio content, so for those we need to provide a text alternative, such as captioning or a transcription.

Users with mobility impairments also use assistive technology. A mobility impairment might mean that the user is unable to use a traditional keyboard and/or mouse, and instead uses assistive software that allows her to navigate the web using voice commands.

Websites also need to be accessible for users with cognitive disabilities (such as dyslexia). This is done primarily through the way we design content and the user interface, so in the context of HTML5, we won’t be discussing their needs.

The First Step to Accessibility: Good Design

The first thing I said during my talk, and I also repeated it several times because it’s important, is this: good design and a good user experience go a very long way toward making a site more accessible. So does writing standards-compliant and clean HTML. Start there, and your job of making sure the site is accessible will be much easier.

Many websites are overly complicated, and most people find the web difficult to use, at least sometimes. For example, you’ve probably filled out online forms that have several fields, many of which seem unnecessary. A shorter and simpler form is not only a better user experience for all your users, it’s also less functionality that needs to be made accessible.

Semantic HTML

Before looking at how adding HTML5 elements can make your page more accessible, make sure that you’re starting out with good code.

You probably have heard the importance of writing semantic, standards-compliant HTML. One reason it’s important is that it improves accessibility. For example, a blind person using a screen reader needs the ability to skip through to different sections of the page, rather than reading the whole page from start to finish. Using heading levels appropriately (H1 through H6) makes this a lot easier. The user can listen to all the section headings and then decide which part of the page he is interested in, if any. (Creating Semantic Structure)

Keeping the content and presentation layers separated is also incredibly important. HTML is for content and structure, and CSS is for presentation and layout. (If you’re not a developer: The Web Standards Model)

HTML Support

HTML5 offers some great ways we can make our sites more accessible – but there’s one catch: not all browsers support these new techniques.

First off, I need to make sure you understand (and this is very, very important, so pay attention): support for HTML5 by any particular browser is not going to be a yes/no question. This takes a little explanation.

The World Wide Web Consortium (W3C) is the main standards organization for the web. A standards organization is any organization that sets technical standards, usually voluntary (i.e., nobody is legally obligated to follow the standards). For example, the American Architectural Manufacturers Association sets the standard for window sizes, so that if you need to replace a window on your house, you can find many manufacturers that make that exact size.

Similarly, the W3C (made up of people, businesses, and other entities) decides how HTML works (as well as CSS and other technologies), and then the companies who make web browsers are in theory supposed to make sure their browsers render HTML according to the W3C specification. Most browsers follow the specification pretty closely, but since they aren’t obligated to, sometimes they do things a little differently. They can’t do this too much, though, because then web pages won’t look right on that browser and nobody will want to use it.

When a new version of HTML comes along, like HTML5, it’s not an all-of-a-sudden thing. It takes years of discussion for the W3C to make final decisions about how a version of HTML is going to work. But the browsers don’t wait until everything is finished, they start implementing it as soon as they can, because it’s a lot of work to implement everything.

The process is very complicated so I won’t explain more, but the gist is that not all of HTML5 is set in stone yet, but browsers have started implementing parts of it. They work at their own speed, so some pieces have been implemented by all of the browsers, and other pieces by only some of the browsers or none of them. HTML5 Accessibility is a great resource where you can find out which browsers support which parts of HTML5.

HTML5 & ARIA

So while there’s cool stuff for accessibility in HTML5, these techniques are not yet supported in every browser. And even when the newest version of a browser supports something, the older versions of that browser won’t be updated to support it, and some people will continue to use these older browsers.

But that’s okay, because we have a backup plan, and it’s called WAI-ARIA (Accessible Rich Internet Applications Suite) or just ARIA for short.

ARIA has some of the same accessibility functions as HTML5, and it’s been around longer, so most newer-ish browsers support it, as well as most assistive technologies.

The difference between HTML5 and ARIA is that ARIA is an add-on of sorts, but HTML5 is your actual semantic page code. For example, this is a new HTML5 element you’d use for the header of your page, where you might have your site title, logo, and main navigation:

<header>
...
</header>

You can do pretty much the same thing with ARIA, at least as far as assistive technology is concerned.

<div role=”banner”>
...
</div>

The nice thing about the HTML5 element is that it’s semantic HTML; that is, it provides meaning to the structure of the page. A div doesn’t do that. So if some browsers don’t support HTML5, but most support ARIA, what do you do? The answer is: use both. It may seem odd to use code that most browsers aren’t supporting, but keep in mind that they will be supporting it in the near future. And you’re building a web page that you want to last a while, so put the good stuff in so that it will be there when browsers are ready to start using it.

Meanwhile, to include both HTML5 and ARIA for this element, simply do this:

<header role=”banner”>
...
</header>

If the page is rendering in an older browser that doesn’t know what <header> is, it will still render the element. Think of it kind of like a <span> – an inline element that doesn’t do anything on it’s own, but you can add CSS styles to it as you wish (except in older IE, see Using HTML5 Semantic Elements Today for a fix). Also note that I just said “inline” – browsers render all unknown elements inline. <header> is a block element in HTML5, and you’ll want to use it that way, so give all your HTML5 elements display:block in your stylesheet, as part of your reset, to make sure you’re covered in older browsers.

As we go along, I’m going to talk about HTML5 elements and their corresponding ARIA roles together, since that’s the way you’ll want to implement them.

One last thing – if you’ve used ARIA before, you may have had concerns that it made your page not validate. Well, great news! Part of HTML5 is that support for ARIA attributes is included in the specification. So just change your doctype from HTML 4 to HTML5, and you’re all set!

HTML5 Elements & ARIA Landmark Roles for Document Structure

Okay, now we’re getting to the good stuff. When you design a web page, it’s visually organized into different areas: a header, navigation, columns, a footer, etc. It’s easy for a sighted user to see the different areas of the page.

We can now use HTML5 elements to convey that same document structure to screen readers and voice recognition software, to allow users to easily navigate to those areas of the page. There are also special ARIA roles called landmark roles that serve the same purpose.

These are some (but not all) of the elements that you can use. This is just a basic overview, so visit the links to get more detail on how they should be used.

HTML5	ARIA	Description
<header>	role=”banner”	Introduction to a page or section. Can contain a heading (H1-H6), site logo, navigation.
<nav>	role=”navigation”	Can be used for various types of navigation such as site navigation, subnavigation, breadcrumbs, previous/next links.
<footer>	role=”contentinfo”	Describes the page or a section of the page. A page’s footer may contain author name, copyright info, privacy policy, etc.
<aside>	role=”complementary”	Information that is tangentially related to the main page content, but can be read separately. Visually you might see this as a sidebar.
<article>	no equivilent	Independent item such as a blog post, article, etc. Think of it as something that could be independently picked up and moved around, such as blog posts in a RSS feed.

To learn more:

• Using WAI-ARIA Landmark Roles
• ARIA Landmark Role Support Tests

Images

Hopefully you’ve already been adding alt text to your images. That’s still important, and actually very important. But please make sure your alt text is meaningful to the users who need it. Here’s what you do: don’t just describe the image. Instead, imagine that someone is reading the page out loud to you. What do they need to say so that you get the full meaning of the image as it relates to the web page? That’s your alt text. (More tips: Five Kinds of “Alt” Text)

In HTML5, there’s something new we get to do with images, and that’s adding a caption that is semantically associated with the image. Of course you’ve always been able to add a caption – usually you just put the caption right below the image, maybe put both of them in a <div> with a nice border around it. But for anyone using a screen reader, the only association between the image and its caption was proximity, and that association wasn’t particularly strong.

Now we have <figure> and <figcaption> that can be used to associate captions with images. <figure> doesn’t replace the <img> tag, instead it’s a container that holds both the <img> and the related <figcaption> (which is optional). It’s not something that’s needed for all images, though. <figure> is used when the image is an essential part of the page content, but can be moved outside the main flow of the page content. For example, a photo that illustrates a newspaper article can be somewhere off on the side, but it’s essential to the article. You wouldn’t use <figure> for other types of images like the logo in the page header.

But wait, there’s more! You can actually use <figure> for other types of content, like code samples, audio, video, charts, poems, etc. And even better: you aren’t limited to one image; perhaps you want to have three headshots with one caption (pictured, left to right are…). You can stick all those images inside one <figure> with one <figcaption>.

These elements are only minimally supported so far, so you should also use the aria-labelledby attribute on your caption.

To learn more: The <figure> and <figcaption> Elements.

Video & Audio

Personally, I think the most awesome part of HTML5 is that it allows browsers to natively play audio and video files. You no longer need a plugin (Flash, Java), you don’t need to build some complicated custom JavaScript solution, and you don’t need to embed YouTube videos just because you don’t know what else to do with your media files.

By using the <audio> or <video> elements, you simply specify a source file (the same way you do for <img>) and the browser takes everything else for you.You do have the ability to change various attributes: whether the media file should loop, preload, and/or autoplay; and whether controls will be displayed (play button, forward, pause, etc.).

One of the great things for accessibility when you use these elements is that since the browser provides the controls, they are much more likely to be accessible. For example, in Firefox and Opera, the media controls are accessible by using the keyboard. This is in contrast to some plugins, where you can only use a mouse to play the video.

You’re probably wondering about video captioning. There isn’t a good solution in HTML5 yet. Meanwhile, you may want to check out alternative solutions such as the Captionator HTML5 Polyfill.

<video> and <audio> are already partially or fully implemented in most of the newer browsers. But keep in mind, when using these elements, you need to put in a backup method to access the multimedia for browsers that don’t support the elements.

More resources:

• Using HTML5 Audio and Video
• Media Accessibility User Requirements (W3C)

Forms

Forms can cause problems for people using screen readers if you don’t make sure it’s possible for them to access all the information they need to fill out the form.

Labels

For those using a screen reader, they need to know what is supposed to be entered in each field, as they can’t actually see the label next to the field. There’s already a solution to this one: the <label> element, which associates the label text with the form field.

<label for="favoritecolor">Your Favorite Color</label>
<input name="FavoriteColor" type="text" id="favoritecolor" />

For checkboxes and radio buttons, use the <fieldset> and <legend> elements to get everything labeled properly.

<fieldset>
<legend>Your Favorite Color</legend>
<input type=”radio” name=”favoritecolor” value=”blue” id=”blue”>
<label for=”blue”>Blue</label>
<input type=”radio” name=”favoritecolor” value=”green” id=”green”>
<label for=”green”>Green</label>
<input type=”radio” name=”favoritecolor” value=”purple” id=”purple”>
<label for=”purple”>Purple</label>
</fieldset>

Required Fields

One tricky thing on forms is what to do when some fields are required. How do you let your user know about this, and then how do you make sure the form isn’t submitted with the required fields not filled out? Previously, you may have marked required fields with asterisks, and then used some JavaScript to validate the form before it was submitted.

But now this functionality will be native in the browser with the required attribute. There’s also an ARIA attribute to go along with it for older browsers.

<label for="favoritecolor">Your Favorite Color</label>
<input name="FavoriteColor" type="text" id="favoritecolor" 
	required aria-required="true" />

This means that the browser will check if the field is filled in, and if not, provide an error message. Screen readers take advantage of this too and they both let the user know that the field is required when it’s initially encountered, and tell the user if the field isn’t filled in upon submittal.

Input Types

Something new in HTML5 is the ability to specify the data type on an input field. Although not a lot of websites have implemented this yet, you’ve probably already seen it if you have an iPhone: when filling out an email address field in a form, you’ll get a slightly different keyboard that has the @ symbol button on the main keyboard, to save you from the extra effort of going to the symbol keyboard.

Some of the other input types are URL, telephone number (you get the telephone keypad), date (you get a date spinner).

iOS is accessible by default, so by using these data types, you not only make the form better for sighted users, you also make it accessible for non-sighted users. You don’t need to worry about that spinner being accessible, Apple’s already taken care of it for you.

Input types will also do some awesome things in desktop browsers – they will provide basic validation (checking if an email field entry is formatted like an email address, for example) and the browser won’t let you submit until you enter properly formatted information. The validation is both a regular visual error message in the browser, and a message provided in a screen reader. (Accessible Client-side Form Validation with HTML5)

Input Patterns

The HTML5 pattern attribute lets you do additional native validation if you need something specific to be entered in a field.

For example, for a credit card number with either 13 or 16 digits, this code will limit the user to entering numbers, and will check to make sure it’s either 13 or 16 digits before submitting:

<label for=”creditcard”>Credit Card Number</label>
<input name="CreditCard" id="creditcard" pattern=”[0-9]{13,16}” 
	title=”A credit card number is 13 or 16 digits.” />

To get ideas of other kinds of patterns you can use, check out HTML5 Example Patterns.

Testing

The reason why you keep hearing that you need to test your web pages in various browsers is that different browsers might render web pages a little bit differently and cause problems. Remember how I said that browsers aren’t required to follow the W3C standards? The things that are rendered differently may seem minor, but you won’t know for sure how they affect your page until you actually look at it in that browser.

When talking about accessibility, it’s also important to understand that assistive technologies such as screen readers or speech recognition software don’t all work exactly the same, and you also should test your website with these technologies as much as feasible.

Apple computers have a built-in screen reader called VoiceOver, and if you have Windows, check out the free/open source NVDA. There isn’t a commonly-used free voice recognition application.

Here are some more resources on screen readers:

• List of Screen Readers (free and commercial)
• Testing With Screen Readers
• Learning How to Test with Screen Readers

Additional Resources

This post only hit the basics of accessibility in HTML5, but use the links to learn more, and here are a few additional links to give you an overview:

• W3C Introduction to Web Accessibility
• WebAIM Introduction to Web Accessibility
• HTML5 and Accessibility (slides)