Chapter 9. Ajax and WAI-ARIA

Before delving into examples of how to implement ARIA, it’s important to know exactly what makes it necessary. ARIA functions as a bridge between web and software accessibility. All of this information—role and state, live regions, focus management—corresponds to the typical information required in a software application.

Most of this is well covered in HTML. Every form field in HTML 4.01, for example, has a role in Microsoft Active Accessibility (MSAA) that clearly corresponds. It’s the new controls introduced by the scripting frameworks that make ARIA useful. Let’s say someone has developed a combo box by grafting a text field onto a select box. Or maybe he created the entire control out of an empty div and some DOM scripting. The way to turn that blob of HTML into something semantically useful again is to define its roles and states in ARIA. To put it another way, ARIA exists so that you can express semantics that can’t be expressed in HTML alone.

Process/mindset

	Plan for Ajax from the start. Implement Ajax at the end.^[21]
	--Jeremy Keith

The progression for designing Ajax applications is to make the page work at each of these stages with each of these technologies:

HTML—the basic structure of the application
CSS—layout and style
Server-side scripts (PHP, Python, ASP, Ruby on Rails, etc.)—adding or changing content on HTTP requests and page refresh
Ajax—getting rid of page refresh to add and change content (using Hijax as necessary, ensuring keyboard access to all functionality)
ARIA—set roles on unidentifiable objects, create programmatically determinable relationships, and keep states and properties up-to-date

In Bulletproof Ajax (New Riders), Jeremy Keith writes:

Before Ajax, a Web site worked like a self-service restaurant. Every time you wanted some information, the browser had to fetch a new page. In a self-service restaurant, whenever you want some food, you have to go up to the counter to order it.
Adding Ajax to a Web site is like hiring a waiter for a restaurant. The customer no longer needs to go to the counter to order food. The waiter will take the order to the counter instead. This results in a much more pleasant dining experience.
Just because you’ve hired a waiter doesn’t mean you can fire the cook. Yet this is exactly what some Ajax applications attempt to do. Not content with having a waiter take orders and bring food, they get the waiter to do all the cooking too.
Cooking should happen in the kitchen. Application logic belongs on the server. It’s better for everyone that way. Your application will work more consistently when it is server-based. The browser environment is simply too unpredictable.

This unpredictability will only increase as your audience accesses your site from more devices, in more situations, and with a growing range of personal preferences. Whether it be due to security reasons or device capabilities, you cannot assume everyone in your worldwide audience will experience Ajax. Layering the experience in a single application so that the environment can transform to meet everyone’s needs. Creating a single flexible application decreases your maintenance costs because all of the various end-user experiences run off of the same code on the server. Keep in mind that a “single flexible application” does not mean making your site work with a single style sheet or set of scripts. Once your application has a solid HTML foundation and the bulk of the functionality is on the server, you can tack on as many CSS and client-side scriptable building blocks as you like. See Chapter 4 for more on creating CSS for different devices.

Roles

In HTML, most of the elements have a defined role and behavior: an a is a link, h1 is a first-level heading, and so on. However, because HTML was primarily designed as a document markup language, there are many objects that HTML does not define. Examples include div and span, which can be used to do any number of things from grouping elements into a section to creating a button. As such, assistive technologies don’t know what to make of them. ARIA provides over 50 roles to choose from, as shown in Table 9-1.

Table 9-1. WAI-ARIA roles^[22]

`alert`	`directory`	`main`	`radio`	`tab`
`alertdialog`	`document`	`marquee`	`radiogroup`	`tablist`
`application`	`grid`	`menu`	`region`	`tabpanel`
`banner`	`gridcell`	`menubar`	`row`	`textbox`
`button`	`group`	`menuitem`	`rowheader`	`timer`
`checkbox`	`heading`	`menuitemcheckbox`	`search`	`toolbar`
`columnheader`	`img`	`menuitemradio`	`secondary`	`tooltip`
`combobox`	`link`	`navigation`	`seealso`	`tree`
`contentinfo`	`list`	`note`	`separator`	`treegrid`
`definition`	`listbox`	`option`	`slider`	`treeitem`
`description`	`listitem`	`presentation`	`spinbutton`
`dialog`	`log`	`progressbar`	`status`
^[22]http://www.w3.org/TR/wai-aria/#roles—February 4, 2008 Working Draft

In the previous chapter, we showed a menu with submenus. Marking the parent ul as a menubar and each list item as a menu item will let the user agent map the role to one of the objects in the OS-level accessibility API. Roles can be used like classes in that a single object can have multiple roles, and as with classes you use a space-separated list. In the case of our menu, it is a structural item and needs only one role:

<ul role="menubar">
  <li role="menuitem"><a href="http://bellevuecollege.edu/about/"
class="first" id="first">About BCC</a>
     <ul role="menu">
        <li role="menuitem"><a
href="http://bellevuecollege.edu/about/goals/">Mission &amp;
Goals</a></li>
        <li role="menuitem"><a
 href="http://bellevuecollege.edu/about/around/">Getting Around</a></li>
...
</ul>

States and properties

As with HTML elements, after you have chosen one, you can tweak it with a variety of attributes. With ARIA roles, we have several properties to choose from. In the case of the menubar, the following are the available properties:

activedescendant
atomic
busy
channel
controls
expanded
live
relevant
templateid

The global states are also available:

datatype
describedby
dropeffect
flowto
grab
haspopup
hidden
labelledby
owns

Note

ARIA properties must be prefixed with aria- as in aria-haspopup—as you will see in our code examples. There is one exception: role does not need the aria prefix. When discussing ARIA properties in text (as in the previous paragraph), we will refer to properties without the prefix.

In the following example, we initially want the menu to be collapsed (aria-expanded="false") and want it to appear in the tab order (tabindex="0", although because we’re using links, they will appear in the tab order as active HTML elements). The aria-haspopup property causes a screen reader to notify a person that submenu items exist:

<ul role="menubar">
  <li role="menuitem" aria-haspopup="true" aria-expanded="false" 
tabindex="0"><a href="http://bellevuecollege.edu/about/" class="first" 
id="first">About BCC</a>
     <ul role="menu">
        <li role="menuitem"><a
href="http://bellevuecollege.edu/about/goals/">Mission &amp;
Goals</a></li>
        <li role="menuitem"><a href="http://bellevuecollege.edu
/about/around/">Getting Around</a></li>
...
</ul>

Handling navigation and keyboard support

In the last chapter, we started handling keyboard support, but one thing was missing. It is very difficult to track and change focus in today’s browsers using only HTML and scripting. Here’s another venue where ARIA can shine.

Since a mouse has only a few events that it can fire, it’s not surprising that mouse events are well handled and standardized: when you hover over an object more information about it might pop up, or when you click on an object it does something. Keyboard conventions aren’t so well developed. A standard keyboard typically has 101 keys (give or take a few) that can be pressed 1 or 2 or 3 at a time. Mac keyboards differ from Windows keyboards differ from Linux keyboards; English keyboards differ from French keyboards differ from Japanese keyboards. I’ve lost track of how many possible keyboard combinations that is….

There are several commonly used practices on Windows—Alt+F typically opens an application’s File menubar. Pressing the Enter key activates selected items, like submitting a form. The Escape key usually allows you to back out of an operation. Arrow keys are used to navigate menus.

However, there are OS-specific keyboard commands, browser-specific keyboard commands, as well as assistive technology-specific. Add on top of those application-specific keyboard commands, and managing keyboard collisions has become an art form in the assistive technology world—and is one of the requirements of Section 508.

Unfortunately for Ajax, it is a relatively new concept. If you define a new component, you will have to define its keyboard support. WAI-ARIA Best Practices describes optionKeyEvent—a function to handle keystrokes for a widget—at http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/#accessiblewidget.

Luckily, there are lots of folks writing scripts to handle this behavior, which can be borrowed, or they are building it into widgets in the toolkits. Example 9-1 shows some of the keyboard support from the Mozilla bare-bones “spreadsheet” example (http://www.mozilla.org/access/dhtml/spreadsheet).

Example 9-1. JavaScript for connecting keyboard commands to widgets

Menubar.prototype.doNavigation = function(event) {
  var bEventContinue = true;  // browser can still use event
  var key = event.keyCode;
  if ((key >=KEY_LEFT && key <= KEY_DOWN) || key == KEY_ESCAPE) {
    var idx = this.getActiveMenuIndex();
    if (idx < 0) {
      idx = 0;
    }
    // if subIndex > −1 a submenu is open - up and down movement will 
occur in it
    var subIndex = this.getActiveSubIndex();
    var subMenuId = this.getActiveSubOpen();
    var menus = this.getMenus();
    var menuLen = menus.length;
    var activeMenuId = menus[idx];
    var curDrop = document.getElementById(activeMenuId + DROP_SUFFIX);

    if (key == KEY_LEFT || key == KEY_RIGHT) {

      var nextIdx = idx;
      if (key == KEY_LEFT) { // left
        nextIdx = (idx + (menuLen-1)) % menuLen;
      }
      else { // right
        nextIdx = ((idx + 1) % menuLen);
      }
      // if drop menu is displayed, close it and open the next one 
or move into submenu
      var bShowNext = this.isActiveOpen();
      if (bShowNext) {
        // current drop is open, see if it has submenu
        if (curDrop) {
          if (subMenuId != null) {
            // submenu is open - close it
            this.hideSubMenu();
            if (key == KEY_LEFT) {
              // find parentItem and set focus to it
              gFocusItem = document.getElementById(subMenuId);
              setTimeout("doFocus();",0);
              return false;
            }
            // if right just close and move to next top level menu 
(which happens below)
          } // end of submenu open
          if (key == KEY_RIGHT && subMenuId == null) {
            // if right arrow and submenu are not open, get current item 
in the drop-down and see if it has a submenu
            var itemIdx = this.getActiveItemIndex();
            var menuItems = this.getMenuItems(activeMenuId);
            var curItemInDrop= document.getElementById(menuItems[itemIdx]);
            var bHasSubMenu = this.hasSubMenu(curItemInDrop);
            if (bHasSubMenu == true) {
               return this.showSubMenu(event,curItemInDrop.getAttribute
("id"));

            }
          }
          // if haven't returned yet - then close the current drop
          curDrop.style.display = "none"; // only one menudrop child per menu
          this.setActiveItemIndex(0);
        }
      }
      this.setActiveMenuIndex(nextIdx);
      var nextMenuId = menus[nextIdx];
      gFocusItem=document.getElementById(nextMenuId + TOP_SUFFIX);
      if (bShowNext == true) {
        var drop = document.getElementById(nextMenuId + DROP_SUFFIX);
        if (drop) {
          drop.style.display="block";
          var menuItems = this.getMenuItems(nextMenuId);
          gFocusItem=document.getElementById(menuItems[0]);
        }
      }
      setTimeout("doFocus();",0);
    }

    if (key == KEY_UP || key == KEY_DOWN ) {
      var itemIdx = this.getActiveItemIndex();
      var bOpen = this.isActiveOpen();

      if (curDrop) {
        // first see if submenu is open
        if (subMenuId != null) {
          // submenu is open - move within it
          var subMenus = this.getSubMenuItems(subMenuId);
          var subLen = subMenus.length;
          var nextSubIndex =subIndex;
          if (key == KEY_DOWN) {
            nextSubIndex = (subIndex +1) % subLen;
          }
          else if (key == KEY_UP) {
            nextSubIndex = (subIndex + (subLen - 1)) % subLen;
          }
          gFocusItem = document.getElementById(subMenus[nextSubIndex]);
          this.setActiveSubIndex(nextSubIndex);
          setTimeout("doFocus();",0);
          return false;

        } // end of if submenus - back to regular processing

        var menuItems = this.getMenuItems(activeMenuId);
        var itemLen = menuItems.length;
        var nextItemIdx;
        if (!bOpen) { // open and set to the first item
          this.showMenu(event, activeMenuId, true);
          itemIdx = −1;
        }
        if (itemIdx == −1) {
          nextItemIdx = 0;
        }
        else if (key == KEY_DOWN ){
          nextItemIdx = (itemIdx +1) % itemLen;
        }
        else { //UP
          nextItemIdx = (itemIdx + (itemLen-1)) % itemLen;
        }

        this.setActiveItemIndex(nextItemIdx);
        gFocusItem=document.getElementById(menuItems[nextItemIdx]);
        setTimeout("doFocus();",0);
      } // end of id curDrop
    } // end of id up/down
  // need to prevent propagation of arrow keys
  /*  try {
      ev.preventDefault();
    }
    catch (err) {
      try {
        ev.returnValue=false;
      }
      catch (errNext) {
        ;
      }
  }*/
  bEventContinue = false;

  if (key == KEY_ESCAPE ) {
      this.closeMenu(event);
      bEventContinue = false;
      if (gFocusBeforeMenus) {
        gFocusItem  = gFocusBeforeMenus;
        setTimeout("doFocus();",0);
      }
      else {
        document.focus();
      }
  } // end of if KEY_ESCAPE
  } // end of if arrow or escape  key
  return bEventContinue;
}

Managing focus

Part of making your keyboard handlers work properly is managing focus changes as a user interacts with your application. Sometimes you will need to move focus to a particular element, whereas other times you will be watching for focus changes. For complex widgets, such as a tree structure, you’ll want the parent to be in the tab order, but all of the children don’t have to be. In this case, put a tabindex on the container element and use activedescendant to change the focus between children. See the following resources to learn more:

WAI-ARIA Best Practices, Section 3.2 Providing Keyboard Focus (http://www.w3.org/WAI/PF/aria-practices/#kbd_focus)
Keyboard-navigable JS widgets (http://wiki.codetalks.org/wiki/index.php/Docs/Keyboard_navigable_JS_widgets)

Dealing with updates

In their article “Making Ajax Work with Screen Readers” (http://juicystudio.com/article/making-ajax-work-with-screen-readers.php), Gez Lemon and Steve Faulkner describe how screen readers use a virtual buffer to interact with elements displayed onscreen. The virtual buffer is usually only updated on page refresh or when the user changes modes. As screen readers get better at handling updates, one of the features in ARIA is the ability to tell a component when and how to present the user with updates as they happen.

ARIA defines four priority settings:

off: Do not update the user.
polite: Update the user when he is not busy.
assertive: Update the user as soon as possible, but do not interrupt the user.
rude: Update the user immediately, interrupting everything, including the last rude update.

For example, as you edit a tweet in Twitter, the number of characters left is updated as you type. If you are sighted, how often do you glance at that number? Probably only when you pause to edit your tweet. Therefore, in this example you would use aria-live="polite" so that when you pause, your assistive technology can update you.

On the other hand, if you were about to send an email to everyone in your address book, you would want an alert to interrupt you as soon as it detected the possibility. Be careful with the assertive and rude roles, though. It may seem like a good idea to have your clock widget reading out every second, but after about half a minute of listening to the screen reader chattering, you will quickly realize the error of your ways. Most of the time in ARIA, as in life, polite is the way to go.

Building on the bare-bones spreadsheet, we can add a function to sort the columns when selected. Using Stuart Langridge’s sorttable script (as described at http://woork.blogspot.com/2008/02/sort-table-rows-using-ajax.html), we need to make the spreadsheet a live region. We make it “assertive,” as we don’t need to interrupt the user, but we do want to notify her that the sort is finished. (We also add class="sortable" to use Stuart’s script.)

<table tabindex="0"  id="table2" class="sortable" role="grid"
aria-live="assertive" aria-activedescendant="row1col1" >

Using Unobtrusive JavaScript, attach onkeydown and onfocus event handlers to the table.

If a component controls another part of the web page or application, explicitly identify this relationship using aria-controls. For someone with sight, you will likely have created visual cues to alert them to changes in content. Using the aria-controls attribute will allow a person using an assistive technology to follow the same path and find the updated content.

aria-flowto

The flowto attribute is a more elegant approach to setting reading order in an application. Instead of setting a numeric tabindex value (which can become a serious pain when the numbers are too close to one another), this attribute allows you to point directly to the next control in the reading order. And unlike tabindex, it’s possible to have multiple controls pointing to the same item (say, the subtotal in a shopping cart), which is perfect for marking up a flowchart, as shown in Figure 9-1.

Assume we use CSS to position the images, using this HTML:

<img src="start.png" id="start" alt="start"
flowto="question-90" />
<img src="90-question.png" id="question-90" alt="The 90's?"
flowto="no yes" />
<img src="no.png" id="no" alt="no" flowto="stop1" />
<img src="yes.png" id="yes" alt="yes" flowto="stop2" />
<img src="stop.png" id="stop1" alt="stop"/>
<img src="stop.png" id="stop2" alt="stop" flowto="hammertime
collaborate" />
<img src="hammertime.png" id="hammertime" alt="hammertime"/>
<img src="collaborate.png" id="collaborate" alt="collaborate"
flowto="listen" />
<img src="listen.png" id="listen" alt="listen"/>

While this is a fun example, it would be more relevant to look at a spreadsheet and specify a reading order through the cells to guide someone through an interpretation of the data. Also note that as of this writing, no screen reader supports this attribute.

Figure 9-1. “Freestyle rapping is basically applied Markov chains” (Source: http://xkcd.com/210/)

aria-labelledby and aria-describedby

Another feature in ARIA is the ability to point from a control to its label and description. We know about the label element discussed in Chapter 5: it defines a label, and binds it to a control. The aria-labelledby attribute is the inverse of that: it assigns the control to the ID of a label elsewhere in the document. The aria-describedby attribute lets you assign a description to a given control as well.

Figure 9-2. Screenshot of http://www.mozilla.org/access/dhtml/button

Figure 9-2 shows the form created by the following code. When someone using a screen reader enters the form, the first description (groupdesc1) should be read. When the focus moves to the Check Now button, its description (buttondesc1) should be read, giving the person additional information about the button.

<fieldset aria-describedby="groupdesc1">
  <legend>Order tracking</legend>
  <div role="description" id="groupdesc1">
    Order tracking has been enabled for all shipments outside of Texas.
 For
    information on orders to Texas, please call 1-555-HELP-NOW for an
automated
    recording.
  </div>

  <div>
    <label for="tracknum">Tracking number</label>
    <input id="tracknum" type="text"/>
  </div>

  <div>
    <span role="button"  tabindex="0" aria-describedby="buttondesc1" >
    Check Now
    </span>
    <p role="description" id="buttondesc1">
      Check to see if your order has been shipped.
    </p>
  </div>
</fieldset>

Using Unobtrusive JavaScript, attach onkeydown and onclick event handlers to the button.

Error handling, part 2

Chapter 5’s discussion of error handling outlines a few issues to watch out for when making forms accessible, including identifying required fields, alerting the user to input errors, and indicating which fields contain errors. WAI-ARIA contains two properties and HTML has one role to address these issues:

aria-required="true": Indicates that a field is required.
aria-invalid="true": Indicates that the field is not valid.
role="alert": Indicates that a section is playing the role of an alert. There is some JavaScript trickery required to make this appear as an alert (adding it to the DOM with the role of alert should cause a browser to fire an alert event to an assistive technology).

Marco Zehe’s blog “Easy ARIA tip #3: aria-invalid and role ‘alert’” ties all of these concepts together in a tutorial with working examples (http://www.marcozehe.de/2008/07/16/easy-aria-tip-3-aria-invalid-and-role-alert/).

Disabling controls

Before ARIA, if a control, such as a “previous page” button, was created with an image link, the only way to disable it was to get rid of the href attribute:

<a><img src="disabled-first-page.gif" alt="First Page"/></a>
<a><img src="disabled-prev-page.gif" alt="Previous Page"/></a>

It is an ugly hack.

Now, we can use the ARIA disabled attribute:

<span role="button" aria-disabled="true" id="FirstButton">
<img src="disabled-first-page.gif" alt="First Page"/>
</span>

Here’s an example of an input element from the Dojo Toolkit. The code is for the text area after the text onChange:. Note the different syntax when dealing with Dojo—disabled doesn’t require a name/value pair:

<input id="oc1" disabled value="not fired yet!" autocomplete="off">

Figure 9-3 shows a screenshot of this form.

Figure 9-3. Screenshot of disabled input area from http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html

Maintaining relationships

As you create new nodes and add them to the DOM, make sure you add them at an appropriate place or use aria-owns to create a meaningful reading order.^[23]

[T]he DOM enables assistive technologies to request the “parent” of the object on which the user is working. However, the DOM hierarchy is acyclic—each node may have one and only one parent, making it impossible to represent all parent/child relationships within a single hierarchy. An example is a treeitem. Here, the user often asks for the container parent such as a folder name. In rich Internet applications, only a subset of treeitems may be available at any one time, and they may be added dynamically without modification to the DOM tree hierarchy—a common occurrence in Ajax applications.

Using aria-owns in the following example, the "dropbox" div is explicitly identified as a child of the "mine" div, even though "dropbox" is not an actual child in the DOM. WAI-ARIA calls "dropbox" an adopted child.

--WAI-ARIA Best Practices, Section 5.2.1

<div role="treeitem" aria-owns="mine">My Documents<div>
...
<div id="dropbox" role="group">
  <div role="treeitem">Chapter 1</div>
  <div role="treeitem">Chapter 2</div>
</div>

^[21] http://domscripting.com/presentations/wd06/hijax/

^[23]http://www.w3.org/WAI/PF/aria-practices/#relations_owning