Pretty image
As we move to a world where more and more people access web applications away from their desks, accessibility for all is becoming a bigger issue than ever. HTML5 can help.

One in every ten people in the world has some sort of disability. That statistic is brought to you by the International Labor Organization. That’s around 650 million people. That’s 650 million potential users of your software, 650 million potential consumers of your product, and 650 million people you should think about when developing web sites.

When we do think about accessibility on the Web, we almost always start by thinking about the blind. After all, the web is mostly a visual medium. We’ve learned a few tricks over the years, like using the alt attribute on our images to describe the images to viewers who can’t see them, but for the most part we’ve been crippled in our ability to make our dynamic web applications accessible.

All of that changes with HTML5. There’s a lot of noise surrounding HTML5, but if we look beyond the buzzwords and hype, we’ll find some enhancements that we can use to dramatically improve the accessibility of our web applications. Let’s explore some of these, starting with enhancements to markup.

Descriptive Markup

HTML5 introduces quite a few new elements that we can use to better describe our content. Not to belabor the obvious, but HTML is a markup language: when we write documents in HTML, we’re supposed to be using markup to describe the content better. To describe the most important heading on the page, we’d use the h1 tag. Then we’d put each paragraph of our page in p tags. We’d use the em and strong elements to describe things that we want to emphasize. We’d use the div element for—well, for too many things. But these elements are there to give the content meaning.

With HTML5, we can use the new header, footer, and section elements to divide our page into logical regions. These new elements describe parts of a page much better than the much-abused div element ever did.

In addition, we also have the new nav and article elements, which screen readers can use to more easily find navigation and content elements. Take a look at this code:

 <header>
 <h1>AwesomeCo</h1>
 </header>
 <nav>
  <ul>
  <li><a href="about">About</a></li>
  <li><a href="services">Services</a></li>
  <li><a href="contact">Contact</a></li>
  </ul>
 </nav>
 <section id="posts">
  <article>
  <header>
  <h1>Lorem Ipsum</h1>
  </header>
  <p>...</p>
  </article>
 </section>
 <footer>
  <!-- some footer content -->
 </footer>

It’s very easy to identify the content and the navigation. The more accurately we describe our content, the easier it is for assistive technology to interpret that content. The screen readers JAWS, Window Eyes, and NVDA handle these new elements very well in Internet Explorer 8.

This all works pretty well for static sites, but we can improve things for applications too by taking advantage of two attributes that HTML5 borrows from WIA-ARIA.

WIA-ARIA is a W3C specification that aims to make web applications more friendly to the disabled. Many of the features of this specification are supported by existing screen readers and browsers, and a few pieces have found their way into the HTML5 specification. The two most useful pieces are the role and live attributes.

Landmark Roles

The role attribute identifies the specific purpose of the element. Some of these roles, like role="navigation", duplicate features provided by the new HTML5 structural elements, but others help us guide screen readers even further. We can define roles like:

  • role="application" which says that we’re working with an application,

  • role="alertdialog" which identifies an alert dialog box,

  • role="document" which identifies a static document,

  • role="menubar" which identifies an application’s menu or toolbar,

and many, many more which you can see by referring to the ARIA specification at the site above.

The role="document" and role="application" roles can be very helpful, as they affect how screen readers interpret keypresses. Inside a document, the screenreader may trap keypresses so that the user can navigate around the document with the keyboard shortcuts in the screen reader. Within an application, the screen reader would send those keypresses on to the application.

Live Regions

One of the most difficult tasks we face when developing dynamic web applications is alerting users to changes we make when we use AJAX or other techniques where we don’t refresh the page. We tend to use visual effects to draw attention to these changes, putting people who can’t see out of luck. The aria-live attribute changes that entirely for the better. Add it to any element you plan to change, and supported assistive technology devices will monitor those regions and alert the user when the content changes.

 <div id="shoppingcart" aria-live="polite">
  <p>Your cart is empty.</p>
 <div>

Notice the polite value? That tells screen readers that they should wait to notify the user so as not to interrupt them if they’re in the middle of something else. There’s also the assertive value, which notifies the user at the first opportunity. The WIA-ARIA roles and live regions help us make our applications and content easier for users to navigate, but we can also improve support for user input.

Improved Forms

When users interact with our web applications, they follow links and fill in forms. For the last 15 years, we’ve only been allowed to use text fields, checkboxes, select lists, and radio buttons. We web developers are an inventive bunch, so we’ve whipped up our own date pickers, sliders, spinboxes, and other widgets. But these widgets aren’t really standardized across the board and can be an absolute nightmare when it comes to accessibility and usability. Just ask anyone who’s ever booked a flight or a hotel room about using date pickers.

HTML5 introduces several new form controls that will improve usability and accessibility of sites. These include:

  • an Email field, which can potentially be linked with your address book and can support one or many addresses

  • A URL field which you use to easily enter valid URLs into forms

  • A Date and Time picker

  • A special data type for telephone numbers

  • A Number field that lets users enter numbers only and has arrows to increment or decrement the number

  • A type for selecting a number in a range, which is usually represented as a slider

These new fields help you describe your form’s input types better, which means that user agents can take advantage of that additional information and present alternative interfaces. Browsers can display the same calendar picker across web sites without relying on JavaScript. Screen readers can implement their own methods for making date entry easier.

The iPhone and iPad display alternative virtual keyboards when they encounter email, URL, and number fields. When you select an email field, the virtual keyboard places the @ and .com buttons in a very visible spot so you don’t have to go into submenus to find them. That alone is a good reason to use these new fields. Accessibility isn’t just about “users with disabilities.” By adding these fields, you improve accessibility for your mobile audience too.

Validation

HTML5 forms also let us specify validation rules that user agents can use to provide quick feedback to end users. We typically validate user input on the server side, which is very important because we can’t always trust that client-side validation works. But we know from experience that letting users know what fields are required is very important. We can add the required attribute to our form fields, which user agents can see.

 <label for="project_name">Project name</label><br>
 <input id="project_name" name="project[name]"
  type="text" required>

The specification also introduces a pattern attribute that takes a regular expression, which we can use to provide client-side feedback to users so they can correct their mistakes right away instead of waiting for a trip back to the server. We’ll keep our server-side validation as a fallback, of course, and we’ll make sure to keep any client-side validation in sync with our server-side validation so we don’t confuse our users.

Unobtrusive JavaScript

Once you lay the groundwork for your site with working, valid, and semantic markup using HTML5, you can improve accessibility further with JavaScript.

When I build web applications, I make sure my sites work 100% without JavaScript, which I know that people using assistive technology often disable. When sites use JavaScript to display modal dialogs, it can confuse these users, so they often turn off JavaScript completely. Once I have a working site, I can use HTML5’s custom data attributes and some JavaScript to make my site work differently.

We start with a simple form that submits to our web application:

 <form method="post" action="/projects" data-remote="true">
  <label for="project_name">Project name</label><br>
  <input id="project_name" name="project[name]"
  type="text" required>
  <input type="submit">
 </form>

This form is full of HTML goodness, but take special notice of the data-remote attribute on the form tag. Custom data attributes let us put any attribute we want on an element. Validators ignore these completely. All we have to do is prefix the attribute with data-. We can then use some JavaScript to snag that value and turn any of our regular forms into ones that post asynchronously. Our web framework can then determine if the request was done as a regular POST or via XMLHttpRequest and deliver the appropriate response.

 $(function(){
  $("form[data-remote=true]").submit(function(e){
  e.preventDefault(); // prevent normal submit
  $.ajax({
  type: "POST",
  url: ($(this).attr("action") + ".js"),
  dataType: 'json',
  data: $(this).serialize(),
  success: function(data){
  $('#results').html(data["render"]);
  }
  });
  });
 });

We watch for the form submit event for any form that has the data-remote attribute set to true. We prevent the form’s default behavior and build up an AJAX request to submit the form instead. We grab the form’s action from the existing form markup and append .js so that this form submits to the url http://example.com/projects.js. Our server-side framework can use this to determine how to respond to the form. If you use Ruby on Rails, you can leverage the routing features to easily respond to this event.

We then take the response, which we expect to be JSON, and modify the page’s contents appropriately. Because we built the form up with semantic HTML5 markup, we can use this handler on any form on our web application. It’s then very easy for us to support rich interfaces while still providing useful fallbacks.

Where to go next

We’ve only scratched the surface of accessibility, but I hope you see how useful HTML5 will be as a tool for improving the accessibility of your sites, for users of assistive technologies and also for mobile users. As we move to a world where more and more people access web applications away from their desks, accessibility for all will become a bigger issue than ever before.

My book HTML5 and CSS3 contains many more examples of how HTML5 can improve the user experience. In addition, I’ll be writing more about accessibility on my blog in the coming months.

Brian Hogan has been developing web sites professionally since 1995 as a freelancer and consultant. He’s also built small and large web sites and web applications using ASP, PHP, and Ruby on Rails. He enjoys teaching and writing about technology, particularly web design and development. He is the author of Web Design for Developers and HTML5 and CSS3. He recently came over to the dark side and has become a development editor for The Pragmatic Programmers.

Send the author your feedback or discuss the article in the magazine forum.