Archive for October, 2008

Using ARIA and jQuery to build an accessible tree – part 1

Tuesday, October 28th, 2008

On jQuery.com’s tutorial page there is an article that outlines how to use jQuery to build a tree from unordered lists called “Turn Nested Lists Into a Collapsible Tree With jQuery.” This seems like a nice trick to have in the toolkit however the article did not take accessibility into account. Thus the tree does not work well for screen reader assistive technology. Using WAI-ARIA it is possible to improve the tree and make a more usable experience for users who are using an ARIA aware browser and assistive technology. This series seeks to demonstrate how to make an ARIA-enabled, interactive tree using the “Turn Nested Lists Into a Collapsible Tree With jQuery” article as a jumping off point.

 

As a reminder we will be marking up the unordered nested lists that follow this layout:

<ul> 

<li>item 1

<ul> 

<li>item 1.1</li> 

<li>item 1.2</li> 

<li>item 1.3</li> 

</ul> 

</li> 

<li>item 2

<ul> 

<li>item 2.1

<ul> 

<li>item 2.1.1</li> 

<li>item 2.2.2</li> 

</ul> 

</li> 

</ul> 

</li> 

<li>item 3</li> 

</ul> 

 

We need to add the ARIA markup that describes a tree and its states to assistive technology. For a description of how this markup works see my posting “ARIA Tree Markup.”

In addition, keyboard event handling is needed for screen reader and keyboard users.

 

Once again, from the “Turn Nested Lists Into a Collapsible Tree With jQuery” article we will start with the following code in the $(document).ready() function:

$(document).ready(function() { 

// Find list items representing folders and 

// style them accordingly. Also, turn them 

// into links that can expand/collapse the 

// tree leaf. 

$(’li > ul’).each(function(i) { 

// Find this list’s parent list item. 

var parent_li = $(this).parent(’li’); 

 
 

// Style the list item as folder. 

parent_li.addClass(’folder’); 

 
 

// Temporarily remove the list from the 

// parent list item, wrap the remaining 

// text in an anchor, then reattach it. 

var sub_ul = $(this).remove(); 

parent_li.wrapInner(’<a/>’).find(’a').click(function() { 

// Make the anchor toggle the leaf display. 

sub_ul.toggle(); 

}); // close the add a click event handler

parent_li.append(sub_ul); 

}); // closes the loop working on each branch

 
 

// Hide all lists except the outermost. 

$(’ul ul’).hide(); 

}); 

 

Define the tree element

In this example the root of the tree is an unordered list. We can use jQuery to programmatically set the role of the list to be a tree. We can add this code to the end of the above function since it is not dependent on any earlier work. In fact we could add it to the beginning as well but let’s not complicate things.

var first_ul = $(”ul”).filter(”:first”);

first_ul.attr(”role”, “tree”);

 

The filter of “:first” causes jQuery to return the first unordered list in the document. If we had several lists which were being defined as separate trees, or if otherwise there were multiple lists and only one is to be a tree then a more elegant selector would need to be used. For example the selector could look for unordered lists that have a class of tree. Refining this is left as an exercise for the reader to do as is needed in any specific application. Back to adding ARIA…

The second line adds a “role” attribute using jQuery’s attr() function and sets its value to “tree.”

 

Defining tree items

Each list item will be given an ARIA role of treeitem. The following jQuery will loop through the DOM and give each list item a new “role” attribute and set it to “treeitem.” We can place the code at the end of the above function.

// define treeitems

$(’ul li’).attr(”role”, “treeitem”);

 

Add state

A tree item has two possible states: expanded and collapsed. To tell which state should be conveyed to assistive technology ARIA defines the “aria-expanded” attribute. We need to add “aria-expanded” attributes to each tree item that has children.

In this example we note that by default only the root tree is being displayed and all children are being hidden (or collapsed). In addition, the example is already determining which tree items have children, so we just need to append to the end of the logic that is working with the branches.

The branches that need to have the “aria-expanded” attribute are represented in the parent_li variable. Add the attribute by placing this line just before the sub-list is appended back to the parent list item:

parent_li.attr(”aria-expanded”, “false”);

 

Naming the branches

Next a name for each branch should be defined to keep the browser from returning too long of a name to assistive technology. For discussion on why a branch with children needs to be specifically given a label, see the discussion on “aria-labelledby” in “ARIA Tree Markup.”

We will use the same technique of wrapping the text that should be used to label the branch in a span element. Currently the code is already determining the item’s text and wrapping it in an anchor tag so we can borrow on this work and wrap the text in a span before it gets wrapped with the anchor tag.

parent_li.wrapInner(”<span id=’a11yLabel”+treeitem_label_i + “‘/>”);

 

The line can be placed after the removal of the sub-list from the parent list item:

var sub_ul = $(this).remove(); 

 

The variable treeitem_label_i is just an index counter we increment by one with each iteration of the loop to create different ID’s for each item. We will have ID’s of “a11yLabel1″, “a11yLabel2″, etc.

 

Then set the “aria-labelledby” attribute on the parent list item to point to the span we just created:

parent_li.attr(”aria-labelledby”, “a11yLabel”+treeitem_label_i);

 

The tree itself should also be given a label so that it accurately conveys itself when the user tabs to it. If an element elsewhere on the page is the best label then use that. Otherwise we can use the first item in the tree. This will ensure that screen readers will have something to say when focus lands on the tree.

The variable first_ul created earlier points to the list that is defined as a tree that we need to label. Using the first span we just created we can set the label for the tree to the span by:

first_ul.attr(”aria-labelledby”, “a11yLabel1″);

 

Tabindex

The tree needs to receive focus when tabbed too. In order to do this a tabindex = 0 is given to the root list. In addition, to keep tab from going to the links in the tree tabindex = -1 is given to them. This way focus can be programmatically set to the elements, but tab will bypass them, giving the user a nice quick way to continue to other parts of the page. (The tree itself will be navigated by using the arrow keys once it has focus.)

Set the tree tabindex = 0 with this line:

first_ul.attr(”tabindex”, “0″);

 

And give the other list items and links a tabindex = -1:

$(’ul li’).attr(”tabindex”,”-1″);

$(’ul li a’).attr(”tabindex”, “-1″);

 

Putting it together

At this point we have the code we need to build ARIA into the default tree that is being created from the nested lists. When we combine the steps outlined to this point we end up with the following JavaScript.

 

        // code

            // the ready event runs after page is loaded

    

$(document).ready(function() {

// Find list items representing folders and

// style them accordingly. Also, turn them

// into links that can expand/collapse the

// tree leaf.

var treeitem_label_i = 0; // index for ARIA labels

$(’li > ul’).each(function(i) {

    treeitem_label_i++;

// Find this list’s parent list item.

var parent_li = $(this).parent(’li’);

 

// Style the list item as folder.

parent_li.addClass(’folder’);

 

// Temporarily remove the list from the

// parent list item, wrap the remaining

// text in an span and a anchor, then reattach it.

var sub_ul = $(this).remove();

parent_li.wrapInner(”<span id=’a11yLabel”+treeitem_label_i + “‘/>”); // use this for ARIA label

parent_li.attr(”aria-labelledby”, “a11yLabel”+treeitem_label_i);

parent_li.wrapInner(’<a/>’).find(’a').click(function() {

// Make the anchor toggle the leaf display.

sub_ul.toggle();

}); // close the add a click event handler

parent_li.attr(”aria-expanded”, “false”); // adding state via ARIA

parent_li.append(sub_ul);

}); // closes the loop working on each branch

 

// Hide all lists except the outermost.

$(’ul ul’).hide();

// ARIA code

// set the outer list to be the tree

var first_ul = $(”ul”).filter(”:first”);

first_ul.attr(”role”, “tree”);

// name the tree using the first item in the tree (for some trees other text on page may be more suitable)

first_ul.attr(”aria-labelledby”, “a11yLabel1″);

// set tabindex

first_ul.attr(”tabindex”, “0″);

$(’ul li’).attr(”tabindex”,”-1″);

$(’ul li a’).attr(”tabindex”, “-1″);

 

// define treeitems

$(’ul li’).attr(”role”, “treeitem”);

});

 

In part two event handling will be discussed and added to the tree so that nodes can be expanded and collapsed. After all, what fun is a static tree? (Astute readers will note there already is some event handling provided but at this point it is mouse oriented. It needs to be device independent, or in JavaScript’s case handle both mouse and keyboard events.) In addition, when the state of a node changes, the ARIA needs to be updated to reflect the change. This also needs to be added to event handler logic.

 

 

References

 

ARIA Tree Markup

Tuesday, October 28th, 2008

A tree is a useful tool for displaying hierarchy relationships. For example, in Windows Explorer a tree is used to show the hierarchy of folders. Trees have been used in web applications for some time, but until recently there was not a good way to convey these to assistive technology such as a screen reader. The most common approach was to use unordered nested lists and the user would have to figure out relationships by keeping track of the nesting to get an understanding of the hierarchy. Which could become tedious and confusing quickly. In addition, if each item was activatable, e.g., was a link, the user would have to do a lot of tabbing to get to an item that was of interest, negating the convenience of expanding and collapsing branches to skip past groups of items that were not what was desired at the moment.

While keyboard handling could be implemented for expanding and collapsing tree items, assistive technology still could not track the items or convey the state of expansion because the user agent (browser) was not providing the information.

WAI-ARIA has an answer to these problems. By using it the role and state information that is needed by assistive technology can now be provided. Namely, the roles of tree for the container object; tree item for each branch or leaf of the tree; and group for groups of tree items that are contained at a level. For some additional discussion of ARIA see an earlier post “ARIA resources.”

 

To illustrate how ARIA markup for a tree is employed let’s walk through an example. In order to focus on the ARIA markup we will leave out details of implementing event handlers that would make the tree respond to user events. A browser that supports ARIA such as Firefox 3 will provide the accessibility information through MSAA though so you can check the results with a screen reader that support ARIA or with Microsoft’s MSAA Inspector tool.

 

The tree

Let’s consider the following tree represented by nested lists:

 

  • Item 1
    • Item 1.1
    • Item 1.2
    • Item 1.3
  • Item 2

     

The HTML would be structured like this:

 

<ul>

    <li>Item 1

        <ul>

            <li>Item 1.1></li>

            <li>Item 2</li>

            <li>Item 3</li>

        </ul>

    </li>

    <li>Item 2</li>

</ul>

 

To turn this into a functioning tree, links can be added to each item that call JavaScript functions to control the presentation of the tree such as hiding and showing the sub-lists.

 

Tell AT that this is a tree

Roles

In order to tell the browser and the assistive technology that this is a tree, ARIA markup needs to be added. Three roles are used in a tree:

 

  • Tree
  • Group
  • Treeitem

     

    The tree role pertains to the container object, in other words the entire tree from the first item through the last item. Assigning the tree role to the unordered list that holds all of the stuff will do the trick for us:

    <ul role=”tree”>

     

    Each item in the tree, whether it is a root node, branch or leaf, is a treeitem. In our example each list item is defined as a treeitem, for example:

    <li role=”treeitem”>Item 1.1</li>

     

    Groups are used to define blocks of related items at the same level. For example, items 1.1 through 1.3 are in a group that expands from “Item 1″ in our example. This is defined using a role of group on the container for the group of items. In this example the nested unordered list is the container. The HTML looks like:

    <ul role=”group”>

     

State

A treeitem is either expanded or collapsed. In a collapsed state the items that are children of the treeitem are not displayed. The state of an item is defined by using the aria-expanded attribute. It has two values: true, false.

TO convey that the “Item 1″ group in our example is expanded we add aria-expanded = “true” to the list item:

<li role=”treeitem” aria-expanded=”true”>Item 1

 

Focus

By default lists do not receive keyboard focus in HTML. However, since this is to be an interactive tree we need to define tabindex for the items in the tree. It is important to define a tabindex for each element in the tree that is wanted to gain keyboard focus, or is not wanted to in cases where it would by default, e.g., a link. (We do not want links that are used in the tree for actions to each individually appear in the tab order. Instead we want the tree to be navigatable with arrow keys after receiving keyboard focus via the tab key, and the next press of the tab key should move past the tree.)

In order to do this we need to use two values of tabindex: 0 and -1. A tabindex of 0 places the element into the tab order, allowing the browser to determine the tab order. A tabindex of -1 keeps an element out of the tab order, but allows it to receive focus programmatically.

In this example, the container list element that is now defined as a tree needs to be placed into the tab order. Thus add a tabindex of 0:

<ul role=”tree” tabindex=”0″>

 

Providing a name when focused upon

The tree itself should also be given a label so that it accurately conveys itself when the user tabs to it. If an element elsewhere on the page is the best label then use that. Otherwise we can use the first item in the tree as long as the item is sufficient enough to name the tree. This will ensure that screen readers will have something to say when focus lands on the tree.

To label the tree we use the “aria-labelledby” attribute to point to a HTML element that has the text for the name that we need. The “aria-labelledby” attribute is placed in the container element—the list element in this example. For example if we have a DIV of:

<div ID=”treename”>Table of contents</div>

We can point to this using

<ul role=”tree” tabindex=”0″ aria-labelledby=”treename”>

 

Putting it together - almost

Combining what we have discussed to this point we get the following HTML with ARIA markup defining the tree.

 

<div ID=”treename”>Table of contents</div>

<ul role=”tree” tabindex=”0″ aria-labelledby=”treename”>

    <li role=”treeitem” aria-expanded=”true” tabindex=-1>Item 1

        <ul role=”group”>

            <li role=”treeitem” tabindex=”-1″>Item 1.1></li>

            <li role=”treeitem” tabindex=”-1″>Item 2</li>

            <li role=”treeitem” tabindex=”-1″>Item 3</li>

        </ul>

    </li>

    <li role=”treeitem” tabindex=”-1″>Item 2</li>

</ul>

 

When this is presented in an ARIA aware browser such as Firefox 3, the tree is presented through the accessibility API to assistive technology such as Microsoft Active Accessibility (MSAA) on Windows. Tree items are conveyed with their names and there state information such as “expanded” for the “Item 1.”

However, at the moment there is a problem. Instead of showing that the name of the first item is “Item 1″ the entire contents of the nested items are also be returned as in “Item 1 Item 1.1 Item 1.2 Item 1.3″. At first this is a puzzling situation as it appears that the name of the first item in our tree is “Item 1″ and it is defined that way in the list item. On closer inspection we discover that the first list item actually encapsulates the group of sub items. Hence the entire contents between the <li>…</li> tags is being set as the name of the first treeitem. This is not what we want!

ARIA has a solution! It is possible to define the label for an element by using the aria-labelledby attribute in ARIA. For those familiar with explicit labeling used in HTML forms, this is a similar idea. It is more flexible in that any element containing text can be assigned, instead of just a Label element. To fix the problem we just need to explain to the browser and assistive technology that we only want “Item 1″ to be used as the name of the first node in the tree.

We can do this by using a Span element and setting it as the label for the treeitem:

<li role=”treeitem” aria-expanded=”true” aria-labelledby=”i1″ tabindex=-1><span id=”i1″>Item 1</span>

 

Final tree markup

The final markup for this tree using ARIA is now:

<div ID=”treename”>Table of contents</div>

<ul role=”tree” tabindex=”0″ aria-labelledby=”treename”>

    <li role=”treeitem” aria-expanded=”true” aria-labelledby=”i1″ tabindex=-1><span id=”i1″>Item 1</span>

        <ul role=”group”>

            <li role=”treeitem” tabindex=”-1″>Item 1.1></li>

            <li role=”treeitem” tabindex=”-1″>Item 2</li>

            <li role=”treeitem” tabindex=”-1″>Item 3</li>

        </ul>

    </li>

    <li role=”treeitem” aria-labelledby=”i2″ tabindex=”-1″><span id=”i2″>Item 2</span></li>

</ul>

 

Remember that when the tree is live and responding to user events that change the state of items such as expanding and collapsing branches, the ARIA information needs to be updated. For example, if “Item 1″ is collapsed the aria-expanded attribute needs to be set to “false”. Finally if the tree is very large and not all of it is loaded into the DOM at once additional management needs to be done such as using “aria-posinset.”

 

References

Xobni and JAWS

Monday, October 13th, 2008

Recently I had read about Xobni in the news. It is a new add-in for Microsoft Outlook that promises to provide a new way to view and organize your mail. I was specifically interested in its search capabilities and the ability to locate conversations with a specific person. So today I installed Xobni for a test drive.

The first thing I noticed is that Xobni.com is very bare-bones by today’s website standards. This is fine with me – perhaps they’re dedicating most of their resources to their product. Being quite basic, the site was quick to navigate and find the download I was looking for.

After downloading the installer I installed the product. The installation program is standard and accessible enough, working fine with the JAWS screen reader. I realize this is not a comprehensive accessibility testing technique and I will point out here this exercise was not meant to be such. I just wanted to see if I could use the tool and if it would do as advertised.

Next up was actually trying to use the functions of the tool. Xobni put a menu item on Outlook 2007’s menu bar, and that is accessible enough. The options included showing and hiding the sidebar, which can be checked and unchecked. I opened the Analytics tool from this menu and it opened a new window that displays a graph of email usage. There was some text in this window that can be read with the JAWS cursor; however it takes careful reading to work out the context. It appears most information is presented in a graphical chart form in this window.

Next up I set out to try what I really wanted to use: the search and conversations features. I ran into an immediate problem: I could not find these features added anywhere in Outlook’s interface. Tabbing the main window didn’t help, and there was no new menu items for searching or displaying conversations. Opening the Help PDF file I learned that there are a couple of keyboard shortcuts built into the tool. Ctrl+~ moves focus to the search bar, and ctrl+shift+` moves focus to the sidebar. (There are a couple of others.

I pressed the key combination to move focus to the search box, and this did work. JAWS reported that I was on an unnamed edit field. (There is no MSAA information available to identify this edit field either.) According to the manual, as soon as you start typing in this field, a window slides over to show results. I am not sure if such a window appeared, however, JAWS was unable to find one, even when reviewing the Outlook window with the JAWS cursor. So this was a dead-end.

I then tried the Ctrl+Shift+~ keystroke to move focus to the sidebar. This also seemed to work, at least focus went to a panel with a button. The button was unnamed and pressing focus movement keys such as Tab and arrows did not do anything. Attempting to activate the unnamed button via keyboard also didn’t do anything that JAWS could detect.

Lastly, it is worth noting that when focus is moved via the aforementioned keystrokes to the Xobni panels, focus cannot be moved back to the rest of Outlook such as the list of email messages via the keyboard. It is necessary to click the mouse in the main interface of Outlook to restore normal keyboard focus and functionality.

Xobni still sounds like a promising tool and I hope that it can include some accessibility support in future releases. Since it is a new tool in its infancy, today’s experience is not surprising although still a bit disappointing.

 

Increasing Accessibility

Sunday, October 5th, 2008

Chris Hoffstader wrote a piece “Eating an Elephant - Part I” that touches on the sometimes overwhelming task of making things from technology to everyday low-tech things accessible. He covers several points from the leaps forward we have experienced with technology today especially when it comes to accessing information, to the struggles there still are both with technology to low-tech things such as how to shop at a brick and mortar store effectively.

 

I particularly enjoyed the parts about the lower tech problems such as traveling and shopping. We often get caught up in thinking about technology and technology solutions but in effect actually get stuck in the information technology (IT) arena for both looking at the issues and bringing greater accessibility to them. Information and information technology is huge, and is getting bigger, and I for one love to have information accessible and available to me whenever and wherever I want it. However, there is more than just reading and writing that needs to be accounted for. No matter how hard one might try, reading is not going to fill your physical stomach or find the shampoo bottle (missing because someone moved it to an unexpected location).

This serves as an interesting barometer of where we are currently and yet how far we need to go. Have we focused the right amount of attention in all of the right areas? Are there some that get more attention, or less attention, than they warrant? How do we decide what should be next on the list of things to solve?

 

We need to find the opportunities and then take advantage of them to improve the world. Philanthropy has seemingly been gaining a foothold as a popular thing to do both as a way to give back and as a way to benefit in maybe yet unseen ways for the giver. For example, Google recently announced Project 10 to the 100 which has the goal to take five great ideas and develop them to help the world in the greatest way possible. This seems like a brilliant concept both because it is a venue and opportunity to explore ideas, and to move forward with a few. What it takes is a vision and a plan. So what are your ideas that’d better the world for everyone? What can you do to make them happen? Even just getting the idea out there for others is a start. Remember there are many types, some that are good brainstormers, while others of us are not so good at that but if we see the idea we are good at making an action plan.