Archive for the ‘Accessibility’ Category

Java Access Bridge and 64-bit Windows

Friday, July 3rd, 2009

 

The question of Does the Java Access Bridge work on 64-bit Windows? Recently came up on Sun’s Java Accessibility mailin list. After some discussion the following was posted by Peter Korn. It is reproduced here in hopes of being useful.

 

“I am writing to confirm to you that the existing 32-bit Java Access Bridge version 2.0.1 does work on 64-bit Vista, and I would expect it also would work with Windows 7. To use it with 64-bit Vista, you will need to do a “by hand” installation, as 64-bit Vista has introduced a pair of new directories for 32-bit files that the existing installer doesn’t know about. You must also use the 32-bit Java runtime (which means your Java applications & the runtime itself will be limited to 2GB of addressable memory). However, all of the other benefits of a 64-bit OS are available to you - e.g. for the other application you want to run.

 

Here are the steps:

 

  1. Download and install a 32-bit version of the Java runtime. This will work in 64-bit Windows, as do most 32-bit applications. Note that it will be installed not into your “Program Files” directory, but into 64-bit Vista’s “Program Files (x86)” directory.
    Download the “Access Bridge 2.0.1 Manual Install (.zip)” - one of the two options you get after following the link “Download Java Access Bridge 2.0.1″ at http://java.sun.com/javase/technologies/accessibility/accessbridge/
  2. Follow the “By hand” instructions at http://java.sun.com/javase/technologies/accessibility/accessbridge/2.0.1/docs/setup.html
  3. Copy the three DLL files “JavaAccessBridge.DLL”, “JAWTAccessBridge.DLL”, and “WindowsAccessBridge.DLL” from the Access Bridge installerFiles directory into your new for 64-bit Vista Windows\SysWOW64 directory. This is where 64-bit Vista needs to have 32-bit DLLs (for most people the full path will be “C:\Windows\SysWOW65″).
  4. Modify your PATH so that it ends with the Windows\SysWOW64 directory (Start Menu-> Computer -> Properties -> Advanced system settings -> Environment Variables -> System Variables -> PATH to add the string “;%SystemRoot%\sysWow64″ to the end of the existing PATH (or at a minimum, that it appears after the entry for “”%SystemRoot%\system32″ in your path).

 

With those changes you should be able to run the JavaFerret and JavaMonkey test tools and see the accessibility information of accessible Java apps (like SwingSet2 which is what I tested with).

 

As to whether your specific AT will support Java in this fashion on 64-bit Vista - that is a question for the AT vendors. I have tested it with NVDA version 0.6p3.2 (latest released version as of today), and NVDA reads the contents of apps accessible Java apps just fine - just as it does on 32-bit Windows.”

 

Finally as of June 2009 it has been reported that JAWS 10.0 does not work with the above configuration. And NVDA is confirmed to be working.

 

jQuery UI 1.7 Accessibility Support

Monday, March 9th, 2009

According to Marco’s Accessibility Blog, jQuery UI 1.7 contains WAI-ARIA support. This an exciting development as it is potentially possible that just by using the out-of-the-box components accessibility can be improved – for free.

Stay tuned to this development as hopefully more exploration and information and experiences will be reported in the coming months.

Programmatically Customizable GUI

Monday, December 1st, 2008

An article on SlashDot points to this article: “Special GUI for your eyes only” which discusses University of Washington research on adapting GUI’s to the abilities of the user instead of the user adapting to the GUI which is commonplace today. The program, named Supple, has the user do various tests testing to find the best way for the user to control the system. The technology can be used for example to determine that a user would benefit from larger than “normal” buttons to provide a larger clicking interface.

It appears that currently the focus is on improving a point and click interface – read mouse. I hope that this concept is furthered and taken to keyboards as well. For example, some users may have no difficulty with a three keystroke shortcut, while others may have the use of one hand and two keystroke combinations on the same side of the keyboard would be easier and faster. Some programs, including Microsoft Word, do allow the user to customize keyboard shortcuts now, but I find the process to often be tedious, time consuming and less than intuitive. Also if the system could help figure out what the best shortcut would be for the long-term that could be help. Is CTRL+H really the best for Find and Replace? Or would I find that I can type that keystroke very quickly and easily and that a far more common task that I complete is creating a hyperlink?

 

Interesting research and interesting ideas… Keep on inventing and sharing.

 

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

Find UISpy

Friday, September 12th, 2008

UISpy has been a difficult tool to find. UISpy is the testing tool for UIAutomation to allow you to see what is being presented to assistive technology. [For the uninitiated, UIAutomation is Microsoft's replacement for Microsoft Active Accessibility (MSAA). In addition its intended to allow the automation of the user interface for automated testing purposes.]

The MSDN blog post “Where is UISpy.exe” is the latest word I have found on how to locate UISpy.exe.

Good luck.

Manual Install of Java Access Bridge

Friday, September 5th, 2008

The Sun Java Access Bridge has an automatic install and a manual installation procedure. Most of the time the automatic one works fine, but there are times it does not. This seems especially true of third party applications that use their own included Java runtime environment (JRE) packaged with their product. When the automatic install does not seem to work try these steps.

Manual Installation steps:

All files to be copied are in <ACCESSBRIDGE_HOME>\install\installfiles

where <ACCESSBRIDGE_HOME> is the folder where the access bridge was unzipped.

 

  1. Copy all .dll files to your windows\system32 folder.
  2. Copy access-bridge.jar and jaccess-1_x.jar to the jre\lib\ext folder of your jvm. jaccess-1_x.jar depends on the version of jvm you are installing into. For example if it is jdk 1.4.1, then you would use jaccess-1_4.jar.
  3. Copy accessibilities.properties to the jre\lib folder for your jvm.

ARIA Resources

Thursday, September 4th, 2008

ARIA it is a technology being mapped out and promoted by the W3C. This technology is used to provide extra information to AT that regular HTML does not do by itself. It works in conjunction with the user agent (browsers). Feel free to add comments of your favorite resources.

 

 

Accessibility of dynamically generated pages by client-side scripting

Wednesday, September 3rd, 2008

 

I recently was asked a question about Ajax frameworks and if how they generate the UI is an accessibility barrier by default, or if some are better than others.

“We are starting to work on a new component using the Yahoo User Interface Library (YUI) data table and saw something that raises a red flag for me. When I viewed the source for our example, I noticed that there is no HTML to look at. Since it is all JavaScript, the HTML is dynamically generated. So I couldn’t verify that heading tags and table column headers were being used.

“The big question, though, is how the screen readers and other AT do their work. Can they function in this environment where everything is dynamically generated or do they require plain old basic HTML with all the heading, label, and column header tags right there for everyone to see?

 

“Here is a link to an example data table on Yahoo’s site: http://developer.yahoo.com/yui/examples/datatable/dt_basic_clean.html.”

 

The cryptic and often hard to follow and trace source code can cause alarm bells to go off for those who are used to checking the accessibility of web pages by reviewing the underlying HTML source code. This is still one of the best ways to determine what exactly is being provided to assistive technology (AT) and if there are any errors. With client-side, dynamically generated pages, we often have to go through a lot more steps to verify what the HTML is.

 

The important thing to remember here is the end result of these JavaScript frameworks—whether it is Yahoo, Google, Dojo or other–is still to produce HTML, as browsers render HTML to the screen to create the visible content. I have included a sample of the HTML from the yahoo example at the bottom of this post. (For one method to get at the HTML of a client-side, dynamically generated page, look at the post “Retrieving HTML from dynamic pages.”)

 

It comes down to functionality a lot of what the widget is doing to how clean the HTML is versus how much hacking has been done to get presentation and functionality to meet the designer’s intent. So each needs to be tested to make sure it is making an accessible interface. For example, the YUI tree view component

is not 100% accessible, as it is not conveying the hierarchy information to the screen reader, this means the user does not know if Label-1 is a child of Label-0 or if they are both root nodes.

 

The original concern of the questioner is does AT pick up what the JavaScript is conveying? In the case of JAWS, and most other modern AT, what it does is wait for the browser to execute the JavaScript (JS) and come up with the final HTML in the DOM. It then reads the DOM to present the page.

So the JS isn’t the problem as much as what the end HTML and event handlers are. I mention event handlers as remember interfaces need to be keyboard accessible as well as mouse, so the drag and drop examples could have some issues for accessibility if used on their own– I have not tested Yahoo’s.

 

ARIA it is a technology being mapped out and promoted by the W3C. This technology is used to provide extra information to AT that regular HTML does not do by itself. It works in conjunction with the user agent (browsers). For example, taking the tree view control, ARIA can be implemented to describe the layout of the tree, and the relationship of the nodes. (See Mozilla’s tree example here.) The browser passes this information to the AT. Currently Firefox 3 has the fullest ARIA implementation. IE 8 will have some although at this time I am not sure how much.

The AT also needs to support this, and that is coming along slowly. JAWS and Window Eyes work best with ARIA in Firefox. JAWS 10 will support the ARIA that IE 8 will have.

 

Depending on how complex your UI is will depend on if you would benefit from ARIA support and planning it. For example, if you want to use the tree view, I’d recommend ARIA.

 

There is a framework that has some ARIA support now: Dojo. IBM has contributed ARIA code to this framework. Depending on your UI and accessibility needs Dojo may be worth a look. According to the “Accessible Rich Internet Applications - MDC” page, the Dijit widgets in the Dojo 1.0 widget toolkit support ARIA. My experience with it is its documentation is bad to non-existent so your mileage may vary, however at the minimum its examples should serve as a useful reference of ways to implement ARIA.

 

Sample HTML from the YUI table example as generated by IE

—-

<!–BEGIN SOURCE CODE FOR EXAMPLE =============================== –>

<DIV class=”yui-dt yui-dt-noop” id=basic> <DIV class=yui-dt-hd style=”BACKGROUND-COLOR: #f2f2f2″> <TABLE id=yui-dt0-headtable> <THEAD> <TR id=yui-dt0-hdrow0-a11y> <TH id=yui-dt0-th0-a11y yuiCellIndex=”0″ yuiColumnKey=”id” yuiColumnId=”0″> <DIV><SPAN>id</SPAN></DIV></TH> <TH id=yui-dt0-th1-a11y yuiCellIndex=”1″ yuiColumnKey=”date” yuiColumnId=”1″> <DIV><SPAN>date</SPAN></DIV></TH> <TH id=yui-dt0-th2-a11y yuiCellIndex=”2″ yuiColumnKey=”quantity” yuiColumnId=”2″> <DIV><SPAN>quantity</SPAN></DIV></TH>

<TH id=yui-dt0-th3-a11y yuiCellIndex=”3″ yuiColumnKey=”amount” yuiColumnId=”3″> <DIV><SPAN>amount</SPAN></DIV></TH>

<TH id=yui-dt0-th4-a11y yuiCellIndex=”4″ yuiColumnKey=”title” yuiColumnId=”4″> <DIV><SPAN>title</SPAN></DIV></TH></TR></THEAD></TABLE></DIV>

<DIV class=yui-dt-bd>

<TABLE id=yui-dt0-bodytable>

<CAPTION>DataTable Caption</CAPTION>

<THEAD>

<TR class=”yui-dt-first yui-dt-last” id=yui-dt0-hdrow0> <TH class=”yui-dt-resizeable yui-dt-sortable yui-dt-first” id=yui-dt0-th0 yuiCellIndex=”0″ yuiColumnKey=”id” yuiColumnId=”0″> <DIV class=”yui-dt-col-id yui-dt-col-0 yui-dt-liner” id=yui-dt0-th0-liner><SPAN class=yui-dt-label><A class=yui-dt-sortable title=”Click to sort ascending” href=”http://developer.yahoo.com/yui/examples/datatable/yui-dt0-sort0-ascending”>id</A></SPAN>

<DIV class=yui-dt-resizer id=yui-dt0-colresizer0></DIV></DIV></TH>

<TH class=”yui-dt-resizeable yui-dt-sortable” id=yui-dt0-th1 yuiCellIndex=”1″ yuiColumnKey=”date” yuiColumnId=”1″> <DIV class=”yui-dt-col-date yui-dt-col-1 yui-dt-liner” id=yui-dt0-th1-liner><SPAN class=yui-dt-label><A class=yui-dt-sortable title=”Click to sort descending” href=”http://developer.yahoo.com/yui/examples/datatable/yui-dt0-sort1-descending”>date</A></SPAN>

<DIV class=yui-dt-resizer id=yui-dt0-colresizer1></DIV></DIV></TH>

<TH class=”yui-dt-resizeable yui-dt-sortable” id=yui-dt0-th2 yuiCellIndex=”2″ yuiColumnKey=”quantity” yuiColumnId=”2″> <DIV class=”yui-dt-col-quantity yui-dt-col-2 yui-dt-liner” id=yui-dt0-th2-liner><SPAN class=yui-dt-label><A class=yui-dt-sortable title=”Click to sort ascending” href=”http://developer.yahoo.com/yui/examples/datatable/yui-dt0-sort2-ascending”>quantity</A></SPAN>

<DIV class=yui-dt-resizer id=yui-dt0-colresizer2></DIV></DIV></TH>

<TH class=”yui-dt-resizeable yui-dt-sortable” id=yui-dt0-th3 yuiCellIndex=”3″ yuiColumnKey=”amount” yuiColumnId=”3″> <DIV class=”yui-dt-col-amount yui-dt-col-3 yui-dt-liner” id=yui-dt0-th3-liner><SPAN class=yui-dt-label><A class=yui-dt-sortable title=”Click to sort ascending” href=”http://developer.yahoo.com/yui/examples/datatable/yui-dt0-sort3-ascending”>amount</A></SPAN>

<DIV class=yui-dt-resizer id=yui-dt0-colresizer3></DIV></DIV></TH>

<TH class=”yui-dt-resizeable yui-dt-sortable yui-dt-last” id=yui-dt0-th4 yuiCellIndex=”4″ yuiColumnKey=”title” yuiColumnId=”4″> <DIV class=”yui-dt-col-title yui-dt-col-4 yui-dt-liner” id=yui-dt0-th4-liner><SPAN class=yui-dt-label><A class=yui-dt-sortable title=”Click to sort ascending” href=”http://developer.yahoo.com/yui/examples/datatable/yui-dt0-sort4-ascending”>title</A></SPAN>

<DIV class=yui-dt-resizer id=yui-dt0-colresizer4></DIV></DIV></TH></TR></THEAD>

<TBODY class=”" hideFocus tabIndex=0>

<TR class=”yui-dt-even yui-dt-first” id=yui-dt0-bdrow0 yuiRecordId=”yui-rec0″> <TD class=yui-dt-first id=yui-dt0-bdrow0-cell0 headers=”yui-dt0-th0 ” yuiCellIndex=”undefined” yuiColumnKey=”id” yuiColumnId=”0″> <DIV class=”yui-dt-col-id yui-dt-col-0 yui-dt-liner yui-dt-sortable yui-dt-resizeable”>po-0167</DIV></TD>

<TD id=yui-dt0-bdrow0-cell1 headers=”yui-dt0-th1 ” yuiCellIndex=”1″ yuiColumnKey=”date” yuiColumnId=”1″> <DIV class=”yui-dt-col-date yui-dt-col-1 yui-dt-liner yui-dt-sortable yui-dt-resizeable”>3/24/1980</DIV></TD>

<TD id=yui-dt0-bdrow0-cell2 headers=”yui-dt0-th2 ” yuiCellIndex=”2″ yuiColumnKey=”quantity” yuiColumnId=”2″> <DIV class=”yui-dt-col-quantity yui-dt-col-2 yui-dt-liner yui-dt-sortable yui-dt-resizeable”>1</DIV></TD> <TD id=yui-dt0-bdrow0-cell3 headers=”yui-dt0-th3 ” yuiCellIndex=”3″ yuiColumnKey=”amount” yuiColumnId=”3″> <DIV class=”yui-dt-col-amount yui-dt-col-3 yui-dt-liner yui-dt-sortable yui-dt-resizeable”>$4.00</DIV></TD>

Acceptable to require older screen readers?

Wednesday, September 3rd, 2008

I had someone ask me this question: How much of an inconvenience it is to ask a user to go from one version of JAWS to another. If, for instance, a person is generally uses JAWS 9 for most of their day-to-day PC activity but they are required to run JAWS 7.1 for a certain application?”

In other words, is it a problem for users to have to go back and forth from one version to another? Is this a common request? Do users typically have more than one version of jaws that they use?

 

This is definitely a usability question, along with a practicality one.

It is possible to multiple versions of JAWS installed, as long as they support the operating system (OS).

For example JAWS 7.1 does not support Vista, so a user on Windows Vista needs to use 8.0 or later.

 

JAWS currently is designed to have side by side installations, so you can have JAWS 7, 8, etc. on a system. (You do have to install earlier ones first.)

Truth is there are shared components which always are updated to the latest. So if you have installed 7.1, 8.0 and 9.0, even when you switch to 7.1 you have a bit of 9.0 running. So the performance could be affected. While it is tempting to say “We only support JAWS 7.1,” users will upgrade ether by choice or necessity, and so even if the product is not supporting JAWS later version, it still needs to be tested with the older version with the later one installed on that machine to ensure the new shared components have not broken something that was previously being counted on as working.

 

Back to the question. Users can switch between versions. It is definitely a nuisance in my view to have to switch screen readers or screen reader versions to get support for a specific app. And a user who is multi-tasking between two apps where previous version works well in one and current version works far better in the other, it can really hurt productivity and be frustrating.

 

While I do not know if it is a common “request” that users use older and newer versions, it unfortunately is a common experience. There are some users who in fact keep two or three different screen readers to access apps depending on their needs.

 

Since the question was framed specifically around JAWS, I will add the following. I’d recommend a rule of thumb to not let any specific JAWS support to get more than one release behind. For example, 7.1 is getting old, it does not support Vista, and currently the shipping release is 9.0 with 10.0 in beta. In addition, as mentioned previously, when requiring an older version of JAWS for a product, ensure that the feature still works when a newer version is also installed on the system as there are shared components that will be updated to the latest version.

And of course, whenever possible create an accessible product that does not require a specific screen reader, or worse yet a specific version of a specific screen reader.