Using ARIA Landmarks – A Demonstration

What are ARIA Landmarks?

ARIA landmarks are attributes you add to elements to create semantically defined sections of a page that allow users of assistive technologies to navigate the page more easily. Think of ARIA landmarks as building a set of “skip to” links like “skip to main content”. You can add ARIA landmarks to define the following regions.

  • application
  • banner
  • complementary
  • contentinfo
  • form
  • main
  • navigation
  • search

By adding these landmarks you are in essence building a set of “skip to” links to allow users to jump to any of these sections and know what the function of each section is.

Adding ARIA Landmarks

Adding ARIA landmarks is very simple. You just need to add an attribute like role=”main” to the appropriate encompassing element. For example, if you have

<div id=”mainConent” role=”main”>…</div>

everything within the <div> will be considered the main content of the page. Similarly, if you have

<div id=”nav” role=”navigation”>…</div>

the contents of that <div> will be defined as the navigation section.

In addition to the role attribute, you can also add the aria-labelledby attribute to explicitly label each section. This is useful for a role like “complementary” where some part of the page is not considered the main point of the page but compliments the main point. A user can jump to this complementary section and know what it is about. For instance, on an “About Us” page on a school Web site that is describing the school, there might be a section off to the side that is showing live score updates from the sports teams. The score information is complementary to the main point of the page but still has important meaning. The code for something like this would look like

<div id="mainContent" role="main">
   About Us

<div id="scores" role="complementary" aria-labelledby="scoresLabel">
   <h3 id="scoresLabel">Live Scores</h3>

This way the user knows exactly what is in the complementary section. Adding ARIA landmarks will have no visual impact on your page so they are an easy way to add more accessibility to your Web page.

Does This Mean I Don’t Have to Provide a Separate “Skip To” Link?

ARIA Landmarks are fairly well supported in screen readers so most users will be able to take advantage of them. There are some older screen readers that don’t support them and some users with newer screen readers might not know how to use this feature. The most helpful data we have on this comes from WebAIM’s screen reader survey. While it shows a 42% increase in awareness of ARIA landmarks over the past year, only 40% of people indicate they use them, and a full 30% still don’t know that the functionality event exists. That being said, if you only provide ARIA landmarks you will be meeting the letter of the law in terms of providing a way to easily skip repetitive navigation, but not providing the traditional “skip to” links will probably make your site more difficult for some screen reader users to navigate. As with almost everything on the Web, we live in the in-between times where newer and better technologies are out there but adoption isn’t high enough to make it the de facto standard. For now, I would still include the “skip to” links in addition to ARIA landmarks.

A Working Model of ARIA Landmarks

Here is a working model of ARIA landmarks with explanations for how to use the various roles.

More Information

W3c ARIA Authoring Practices

Another blog post about using ARIA Landmarks

HTML5 Section Elements and ARIA Landmarks

Accessible “Required” Fields Using aria-labelledby

The Problem

Indicating that a particular form field is required can prove problematic for people with visual disabilities. Here is how a required field is normally implemented.


The problem with this is the text “Required” is hardly ever heard by a screen reader user since it is not part of the label.

Solution #1

The main option to make the “required” message accessible has been to include the “required” text with the form label itself.

Please note that this is a perfectly accessible and correct implementation, however, some people don’t like to implement it this way because it impacts the aesthetics of the page too much.

aria-labelledby to the rescue

By using aria-labelledby you can simply make both “First Name” and “Required” into labels.

   <span id="firstNameLabel">First Name</span>
   <input type="text" name="firstname" id="firstname" aria-labelledby="firstNameLabel firstNameRequired" />
   <span id="firstNameRequired">Required</span>

When a screen reader user enters this form element, they will hear something similar to “First Name. Required. Edit. Blank.” Here is a working demonstration of this technique. This blog cannot properly display input elements with aria-labelledby attributes within the post, so the examples must be viewed from a different site.

Accessible Date Input (and more) Using aria-labelledby

The Problem

Web forms frequently ask for a single piece of information that is broken up into multiple input fields. The most common examples of this are dates, phone numbers, and Social Security numbers. The problem with these is that the way they are frequently implemented can cause difficulties for people with certain disabilities, and they also don’t technically meet accessibility standards. Here is how they are frequently implemented.

Here are the problems with this technique.

  1. “Select a date” is a label (although many times it isn’t even made into a label) but it is not attached to a form element. That is understandable because which form element would you attach it to. You are only allowed to associate a label with one input element, so it usually does not get associated at all.
  2. When the user goes to each of the “Month”, “Day”, and “Year” input elements, since there is no explicit label the user must guess from the context what is being asked for. I daresay most screen reader users have probably become quite adept at this skill out of necessity. Additionally, screen readers applications now attempt, with varying degrees of success, to discern a relationship between two elements when none is explicitly defined. Screen reader users will usually hear something like the following when trying to enter information.
    1. When entering the month, “Select a date. Combo box. Jan. To change the selection use the arrow keys.” (It’s possible they won’t even hear “Select a date”)
    2. When entering the day, “Combo box. 1. To change the selection use the arrow keys.”
    3. When entering the year, “Combo box. 1990. To change the selection use the arrow keys.”


We can make a much more accessible implementation of this using the aria-labelledby attribute in place of explicitly tying a form label to an element with the “for” and “id” attributes. The aria-labelledby attribute lets us attach multiple labels to a single input element. In the following code each input element is linked to two different text elements by the aria-labelledby attribute.

   <span id="selectDate">Select a date</span>
   <span id="monthLabel">Month</span>
   <select name="month" id="month" aria-labelledby="selectDate monthLabel">
      <option value="Jan">January</option>
      <option value="Feb">February</option>
      <option value="Mar">March</option>
   <span id="dayLabel">Day</span>
   <select name="day" id="day" aria-labelledby="selectDate dayLabel">
      <option value="1">1</option>
      <option value="2">2</option>
      <option value="3">3</option>
   <span id="yearLabel">Year</span>
   <select name="year" id="year" aria-labelledby="selectDate yearLabel">
      <option value="1990">1990</option>
      <option value="1991">1991</option>
      <option value="1992">1992</option>

In this case a screen reader will read something similar to the following:

  • When entering the month, “Select a date. Month. Combo box. January. To change the selection use the arrow keys.”
  • When entering the day, “Select a date. Day. Combo box. 1. To change the selection use the arrow keys.”
  • When entering the year, “Select a date. Year. Combo box. 1990. To change the selection use the arrow keys.”

Here are two working example of this technique with some CSS styling. This blog cannot properly display input elements with aria-labelledby attributes within the post, so the examples must be viewed from a different site.

The Catch

If you implement your form in this way you may run into an issue. Some accessibility checkers will say it’s invalid because you are not explicitly tying a <label> to an <input> element. In my opinion this is a perfectly valid way to present a form and the accessibility checkers need to update their criteria. This is an example of where machine validation doesn’t rule the day.

IT Accessibility News – June 2011

Cognitive Accessibility and the Web

When we talk about Web accessibility, the conversation is often dominated by issues dealing with visual or auditory disabilities. This is the case because often times the problems and solutions are very clear cut. It might be expensive to solve, but understanding the nature of the problem and what has to be done to solve it are easily graspable – you provide alternative text for images, you caption videos, etc.

On the other end of the spectrum, cognitive disabilities are not often discussed when we talk about designing Web content. This is because the problems and solutions related to these disabilities are frequently harder to easily quantify. For example, is it difficult to follow the flow of information on a Web page? Usability testing might reveal the answer to that, but just looking at the page might not help you much.

If you want to learn more about this, WebAIM has a good article on Evaluating Cognitive Web Accessibility.


One of the announcements that came out of the Google I/O Conference this year was the release of ChromeVox, a Chrome OS screen reader. ChromeVox comes as part of the new ChromeOS, and it can be added to the Chrome browser as an extension. You can download ChromeVox and read more about its release.

Accessible Forms

As I look at various Web pages to assess their accessibility, there is one simple step Web page designers can take to make their pages more accessible that will have little to no impact on the way your page displays visually – make sure all of your form elements are accessible. It’s easy, and often all that is needed is some behind-the-scenes code that won’t disrupt your visual layout. I’ve put together a little tutorial on accessible forms with some links to other resources as well.

Audio Descriptions – An Experiment

In a previous edition of IT Accessibility News I brought up the topic of audio descriptions for videos. Audio descriptions are a separate audio track in the video that describes important information conveyed only through the video track. Think of it as alternative text for videos. Audio descriptions are also a requirement for WCAG 2 Level AA conformance.

Creating audio descriptions can be challenging because they are very costly to create. They either require a significant financial investment to have someone create them for you (more expensive than captioning) or they require advanced technical skills to create them yourself. I’ve been working on an experimental solution to facilitate providing audio descriptions more easily. It’s not a perfect solution, but it solves a lot of problems. Any feedback you have is welcome.

A Humorous Look at Automatic Caption Creation

Rhett and Link, a local Web comedy team duo, who are also NC State graduates, have a humorous look at Google’s automatic captioning service. They do a version of the “telephone” game with Google by uploading a video, then rerecording the video with Google’s automatic transcription as their new text, then recording the video again with the next version of the transcription. Watch Rhett and Link’s ULTIMATE Caption Fail.

HTML 5 Video, Text Tracks, and Audio Descriptions Made Easy (or at least easier)

First, HTML5 Video and Text Tracks

One of the really powerful features of HTML5 video is the ability to add in text tracks, like for captions and subtitles, and have them automatically play back synchronously with the video. The text tracks simply need to be in the WebVTT format, which is similar to the SRT format but with some additional functionality. Unfortunately, because the spec for WebVTT is so new, none of the browsers have implemented this functionality yet.

I wanted to be able to easily add text tracks (for a reason you will see later) to HTML5 videos. I found a jQuery script that would automatically parse and display SRT files that were included in the <text> element inside a <video> element. I took that concept and made modifications so I could

  1. add multiple tracks instead of just a single track
  2. changed where the output of the text tracks would appear
  3. added support for WebVTT files – well, at least a basic version of WebVTT

Here are the basics.

1. Add these two lines to the <head> section.

<script src=""></script>
<script src="html5texttrack.js"></script>

2. Define a video

<video id="vid" width="480" height="270" controls tabindex="0">
     <source src="myvideo.mp4" type="video/mp4" />
     <source src="myvideo.webm" type="video/webm" />
     <source src="myvideo.ogg" type="video/ogg" />

     <track kind="caption" src="captions.vtt" srclang=en label="English" />

     <!-- fallback goes here for browsers that do not support the video tag -->

3. Define an area to insert the captions

<div id="captionBar"></div>

4. Add this JavaScript after the <video> element

loadTextTrack({videoId:'vid', // the ID of the video tag
               kind:'caption', // the kind of track
               srclang:'en', // the language of the source file (optional)
               targetId:'captionBar'}); // the ID of the element into which to insert the timed text

5. Define some CSS

<style type="text/css">
#captionBar{width: 480px; position: absolute; top: 280px;padding: 3px 10px; text-align:  center; color:#fff;background-color:#000; font-family:  Helvetica,Arial,sans-serif; font-size: 0.9em; font-weight: bold;min-height:3.6em;}

Here is the resulting video.

video with visible captions

Download the Script

Download the html5texttrack.js file to include in your own projects.

An important note – this script does not support all the features or formatting of WebVTT. It supports just enough for me to accomplish this next step.

Now, on to Audio Descriptions

If you have never heard of audio descriptions think of the them as alternative text for video. They are a separate audio track in a video that describes important information conveyed only through the video track. Here are two samples of audio described video: a clip from the movie The Miracle Worker, and a clip from an animated version of Hamlet.

Providing audio descriptions for videos is a requirement in order to meet WCAG 2 Level AA conformance (Guideline 1.2.5) and is one of the options to meet Level A (Guideline 1.2.3).

Providing audio descriptions can be challenging for a number of reasons.

  1. It is very expensive to have third-party vendors produce them – significantly more expensive than making captions.
  2. Creating audio descriptions is an art form. One of the challenges is fitting the descriptions within the empty audio sections of the existing video, usually when the original video was never produced with keeping large empty slots available to insert additional content. Then you have to find the balance of how verbose to be and still keep within those blank spots.
  3. You usually have to know how to use a movie editor in order to insert the audio description track.

JavaScript + ARIA + Screen Readers = Easier Audio Descriptions

One potential solution to aid in creating audio descriptions is to leverage several technologies that are already present in Web browsers and in assistive technologies. What if we could just provide a time stamped text file with the audio descriptions that needed to be spoken, and we use JavaScript to parse the file, and use a text-to-speech (TTS) engine to convert that to actual speech? One solution would be to provide some time of application, like a Flash app or browser plug-in, to provide the TTS functionality, however, most people who need the audio descriptions already have a TTS application running on their computer – their screen reader. All we need to do is take the time stamped text file and synchronously display the audio descriptions in an ARIA Live region. That way the screen reader will read all of the audio descriptions as they change.

Here is the same video from earlier but using this technology to incorporate audio descriptions. Please note, the first audio description does not show up until about 37 seconds into the video.

video with visible captions and audio descriptions

A couple of things are being done here.

  1. There are two ARIA Live regions, one for the captions and one for the audio descriptions. The cations area is set to aria-live=”off” and the audio description area is set to aria-live=”assertive”.
  2. There is a simple form to toggle the audio description ARIA Live region from “assertive” to “off” so that the user can choose not to have their screen reader voice the audio description changes.

Here is the pertinent code.

<video id="vid" width="569" height="320" controls tabindex="0">
    <source src="../source/headingsmap/headingsmap2.mp4" type="video/mp4" />
    <source src="../source/headingsmap/headingsmap2.webm" type="video/webm" />
    <source src="../source/headingsmap/headingsmap2.ogv" type="video/ogg" />

    <!-- the track tag is not currently implemented in any browser -->
    <track kind="caption" src="../source/headingsmap/captions.vtt" srclang=en label="English" />
    <track kind="audiodescription" src="../source/headingsmap/audiodescriptions.vtt" srclang=en label="English" />
    <!-- fallback if browser does not support the video tag -->
    <p>This browser does not support HTML 5 Video and thus cannot demonstrate this technique.</p>

<div id="captions">
    <div aria-live="off" id="captionBar"></div>

<div id="audio_description">
    <h2>Audio Description</h2>
    <div aria-live="assertive" aria-relevant="text" id="descriptionBar"></div>
            <legend>Toggle Audio Description Voicing</legend>
            <input id="on" type="radio" name="onoff" checked="checked" value="on" onclick="javascript:$('#descriptionBar').attr('aria-live','assertive')" />
            <label for="on">On</label>
            <input id="off" type="radio" name="onoff" value="off" onclick="javascript:$('#descriptionBar').attr('aria-live','off')"/>
            <label for="off">Off</label>

<p><a href="../source/headingsmap/captions.vtt">Caption source file</a></p>
<p><a href="../source/headingsmap/audiodescriptions.vtt">Audio description source file</a></p>

<!-- calls the function to parse the text track and display it in the container -->
<script type="text/javascript">
    loadTextTrack({videoId:'vid',kind:'caption', srclang:'en',targetId:'captionBar'});

<!-- set the default value for the audio description voicing to on -->

If you don’t have a screen reader capable of voicing the audio descriptions for you, here are a couple of options.

  1. View a screen cast of JAWS reading the audio descriptions from this video at a fast voice rate.
  2. View a screen cast of JAWS reading the audio descriptions from this video at a slow voice rate.
  3. On Windows, download NVDA, a free and open source screen reader, and try it out for yourself.

This approach does have some shortcomings, like

  1. The developer does not know the speech rate at which the the user’s screen reader is set. This makes it impossible to ensure that an audio description will not overlap important parts of the original audio track.
  2. It requires the user to have a screen reader that supports ARIA Live regions, which not all do yet.

Even with these disadvantages this opens the door for making the process of creating and providing audio descriptions much more achievable without a major investment of money or technical skill development. Audio descriptions are one of the most often neglected aspects of making accessible Web content, so hopefully this will help make them more prevalent.

Where This Might Lead To?

One possibility of implementing audio descriptions this way is you could create a database of audio descriptions that could be dynamically pulled into videos anywhere on the Internet. Currently this script pulls up a plain text file for the audio description, but it would be fairly simple to make the source point to a database. Implementing something like this is similar to some of the early efforts behind collective captioning of YouTube videos, where anyone could provide captions but everyone would benefit.

A Tool to Help You Out – The Movie Time Bookmarklet

If you do want to create audio descriptions this way, one of the trickiest parts is lining up the start of the audio descriptions with the start of a blank space in the audio track. Here is a tool I have developed to more easily get exact time stamps from a movie. It is a bookmarklet, and to use it

  1. Go to and add the link on that page to your bookmarks. Note, you are not adding a bookmark to the page itself, but rather a bookmark to the link that says “Movie Time” on that page.
  2. Browse to any page with an HTML5 video tag, like either of the examples in this blog post.
  3. Click the bookmarklet from your browser’s bookmarks.
  4. Video player controls will appear above the video to help you line up precisely where you want a particular audio description to start.

A couple of very big disclaimers about the Movie Time Bookmarklet.

  1. This tool comes as is. So far I have only developed it far enough to handle what I need it to do.
  2. This tool will only work with HTML5 video tags.
  3. This tool will only work with the first HTML5 video tag on a page if more than one video tag exists.
  4. If you have any suggestions for the tool I’m happy to take them but cannot promise anything.

I do have some plans for this tool in the future, but I’m not sure when I’ll be able to get to them, so I decided to make it available now as it is.