Progressively enhanced tree that works [was RE: Tree sample code]

Cynthia & others, will you try this version?

I made 3 changes which I believe make the Microsoft tree satisfy 
everyone's requirements (backwards compat with Firefox and progressive 

1. Add role="presentation" on the <li> elements -- this avoids cluttering 
the a11y hierarchy for the tree so that the automation 
level/posinset/setsize calclulations can happen
2. Add role="presentation" on the <img> elements -- also avoids clutter. 
The image is presentational because the same info is provided via 
3. Remove aria-setsize, aria-posinset and aria-level. This allows it to be 
automatically computed by the UA.

With these changes, legacy clients will still expose it as nested lists of 
links. However, newer ARIA-capable clients will now expose the correct 
structure, as well as level/posinset/setsize. The role attribute, 
including role="presentation" do not affect the legacy clients at all.

I didn't change this file but here it is for completeness:

Keyboard issue needs discussion: One thing I don't like is that it uses 
tab to go from item to item. I think that makes sense in older UAs, but in 
new ARIA-enabled ones when the user hears "treeitem Animal, collapsed, 1 
of 3 depth 2", they're going to think they can use arrows to navigate. For 
a shipping widget the script should determine if it's an ARIA client and 
if so expose the new keyboard mechanism. I don't know of any simple way to 
determine if something supports ARIA, other than checking the UA string 
and having each script know which version of which browser supports ARIA. 
It's an ugly way but I believe it's necessary.

- Aaron

Cynthia Shelly <>
Aaron M Leventhal/Cambridge/IBM@IBMUS
George Young <>, "" 
<>, "" <>
09/06/2008 05:23 PM
RE: Tree sample code

Comments inline…
From: Aaron M Leventhal [] 
Sent: Saturday, September 06, 2008 3:42 AM
To: Cynthia Shelly
Cc: George Young;;
Subject: RE: Tree sample code

The graceful degredation might work if you put role="presentation" in the 
right places. Let's work together on that. 
Yes, please.  I’d like for this to be able to work.

In general need to "circle the wagons" on ARIA implementations so that the 
same things work in both IE and Firefox. 
Can we all agree to try out our ideas in each other's implementations or 
at least make sure the ARIA user agent implementor's guide reflects the 
algorithm you will use when exposing the positional info to the AT. 
Yes, that seems reasonable.

If you can read between the lines, I'm honestly just worried that we're 
all doing different things without checking with each other and trying it 
out with the currently shipping implementations that already work, or even 
checking it against the ARIA spec or implementors guide. If everyone 
structures their test widgets slightly differently, any 2 implementations 
will work differently. Authors will end up with a mess. IOW please just 
take this as me hoping we can go back and forth until we agree to do trees 
the same way, not to mention menubars, combo boxes and other complex 
composite widgets with potential structural choices. 
Totally agree.  I remember 1997, and I don’t want to go back there J

- Aaron 

Cynthia Shelly <> 
Aaron M Leventhal/Cambridge/IBM@IBMUS 
George Young <>, "" 
09/06/2008 12:52 AM 
RE: Tree sample code

#1 is probably just do to our inexperience.  If it’s not needed, that’s 
So, #2 is the point of this code sample.  Use the native semantics as far 
as they go, and then progressively enhance with ARIA.  I feel pretty 
strongly that this type of graceful degradation pattern should be 
supported if we want accessibility in the broadest range of user agents.   

As a side note, I am getting position and nesting info with IE 8 Beta 2 
and JAWS 9.0.2169 with the virtual cursor turned off, and I’m also seeing 
it in MSAA description field in Inspect32.  The child count is incorrect, 
and I haven’t yet figured out why. 
From: Aaron M Leventhal [] 
Sent: Tuesday, September 02, 2008 5:56 AM
To: Cynthia Shelly
Cc: George Young;
Subject: Re: Tree sample code 

Here are my comments on Microsoft's tree sample: 

1. It uses aria-level, aria-setsize and aria-posinset when it doesn't need 
The idea is that authors only need to do that if the tree is not DOM 
complete -- iow it's loaded dynamically. When the entire tree structure is 
there the user agent is supposed to calculate that info from the 

2. It uses <li><a/></li> constructs. 
This seems to be to allow for graceful degredation for non-ARIA clients. 
However, it means that the tree has list, list item and tree item objects 
mixed together, and no longer looks like a tree widget to current 
generation ATs. Neither current ATs nor Firefox 3 will process the 
structure and automatically provide info like the level, posinset and 
In general, the current implementors guide algorithm will not work with 
this tree. So either the tree needs to change, or the impl guide algorithm 
or both. 

What do you suggest? 

- Aaron 

Cynthia Shelly <> 
"" <> 
George Young <> 
07/07/2008 11:21 PM 
Tree sample code


As promised, here is a zip of the tree sample I demo’d at the face to 
Tree.htm uses only nested unordered lists of links (with onclick handlers) 
to achieve tree behavior.  JAWS in virtual cursor mode with medium 
verbosity does a good job of reading the list levels.  Tab+enter opens and 
closes the tree levels. 
Ariatree.htm is the same tree, with aria markup added to the links.  With 
virtual cursor turned off, list level information is exposed to MSAA. This 
was tested with IE8 beta 1 and JAWS 9.  There are a few bugs in what is 
exposed to MSAA by IE in this early build, which will be fixed. 
I’ve copied George Young, who wrote the original tree, to which I added 
ARIA for the CSUN demo.  George is the best person to work with on 
combining this tree with any other samples that have more extensive 
keyboard handling features.[attachment "" deleted by Aaron M 

Received on Monday, 8 September 2008 09:54:38 UTC