Issue 56 - tree v. HTML list; with code sample (Was: Tree sample code)

Cynthia Shelly wrote:

> As promised, here is a zip of the tree sample I demo’d at the face  
> to face.

I took a stab at implementing the ARIA tree widget based on the  
previous example posted by Cynthia and George.

http://cookiecrook.com/test/aria/tree/ariatree.html
http://cookiecrook.com/test/aria/tree/ariatree2.html

The second example has a few more markup elements and CSS styles for  
the sake of visual UI, but the JavaScript functionality is the same.


Major differences between these and the previous example:

1. The previous example utilized native browser focus on subtree links  
within each treeitem. In order to keep focus on the tree node and  
maintain aria-activedescendent via script, I removed the natively- 
focusable subtree links. Otherwise, I would have had to fight the  
browser for focus. See question #1 below.

2. The previous example placed the role of parent treeitems on the  
anchors instead of on the list items. While this was structurally  
sound, it had the disadvantage of not nesting treeitems and groups  
inside the DOM hierarchy of their respective ancestor treeitems. The  
current example does, and uses a controller span (span[aria-controls])  
to intercept mouse events. I think this is a cleaner solution, but  
would love feedback on whether or not you all think there is an even  
better solution.


Notes:

1. Like the previous example, the aria-* attributes are written into  
the HTML so that it's easy to see structure from viewing the page  
source, but the intended final case is to assign all those properties  
to the DOM via JavaScript.

2. Events are handled by the main tree node (which acts as the  
delegate or firstResponder); mouse and key events are not handled by  
individual tree items. I did not try out a list that uses Ajax-loaded  
items, but it will work the same, assuming all the elements are added  
to the DOM correctly. In other words, when adding items to or removing  
items from the list you don't have to worry about adding and removing  
the event handlers; that part is maintained by the main tree widget.


Questions:

1. In a focusable widget such as a tree control, where the script is  
meant to maintain aria-activedescendent, what should authors and  
implementers do about natively-focusable elements (such as links and  
form elements) in the subtree. For example, if you have a tree control  
where each of the tree items contains a link, then what should happen  
when a user "tabs past" the focusable widget. Currently, all browsers  
then tab into the first link in the widget, which seems quite  
redundant. For simple controls like a list or tree, it might be okay  
to advise against redundant subtree controls, but more complex widgets  
like treegrids will almost certainly contain focusable subtree elements.

2. I'm not entirely sure why all the examples I've seen of this in the  
past use real img tags for the expanders. I assume it has something to  
do with backwards compatibility, but my understanding of the intention  
is that the existence of the aria-expanded attribute should  
communicate everything necessary to the accessibility API, instead of  
the script communicating the meaning of expanded or collapsed via the  
unlocalized alt attribute of an image. For this reason, I left the  
expander in this example as an empty element styled with a background  
image. If the expanded state needs to be communicated to the DOM in  
some way other than via the aria-expanded attribute, why?


Cheers,
James Craig

Received on Monday, 28 July 2008 19:12:54 UTC