Imagine the Tree View-Widget as described in the WAI-ARIA Best Practices Working Draft. Of course you can implement this widget however you like using the denoted WAI-ARIA roles tree, treeitem and group. But certainly the most effective way would be – based on the Progressive Enhancement-Principle – a solid ground in markup which can be understood by nearly all user agents and assistive technologies. In my opinion the best alternative of a Tree View-Widget would be an unordered list like the following:

<ul>          
    <li>Item 1</li>
    <li>Item 2      
        <ul>
            <li>Item 2.1</li>
            <li>Item 2.2</li>            
        </ul>
    </li>
    <li>Item 3</li>
</ul>

Due to the markup that comes with the unordered list you can obtain all needed information to build your Tree View: the number of treeitems (out o the number of <li> elements) , the levels (out of the nested <ul> elements) and dependencies (out of the position of the nested <ul> elements). So you can easily map all needed WAI-ARIA Roles and States:

<ul role="tree">          
    <li role="treeitem" tabindex="0">Item 1</li>
    <li role="treeitem" tabindex="0">Item 2      
        <ul role="group" expanded="false">
            <li role="treeitem" tabindex="0">Item 2.1</li>
            <li role="treeitem" tabindex="0">Item 2.2</li>            
        </ul>
    </li>
    <li role="treeitem">Item 3</li>
</ul>

If you now check your new ARIA-Widget with an Accessibility Inspection-Tool like Inspect Objects from Microsofts Active Accessibility 2.0 SDK Tools through focusing “Item 2” you´ll soon figure out a major misbehaviour:

Especially looking at the “Description”-Row you can figure out that the treeitems on level 1 are mapped correctly to the MSAA (“2 of 3”), but not the ones in the sublevels. The text displays “with 0” what means that the assumed sub-treeitems are not correctly mapped. A look on the “Name”-Row shows why: the sub-treeitems are mapped as the name of the treeitem.

The primary solution for this issue can be found in the Example of building a Tree Widget in the WAI-ARIA-Working Draft. A group that belongs to a treeitem always has to be placed after the according treeitem (or at least should be referenced to it through the state “owns” in the treeitem). So the nested unordered list should be outside of its <li> element. Since there is no way to achive this structure in the original markup (the only element that an unordered list can include is a <li> element, even though most browsers would render another unordered list properly), another code manipulation has to be done to bring treeitem and its sub-treeitems on one level. Wrap your desired treeitem in a <span> or <div> element:

<ul role="tree">          
    <li role="treeitem" tabindex="0">Item 1</li>
    <li>
        <span role="treeitem" tabindex="0">Item 2</span>
        <ul role="group" expanded="false">
            <li role="treeitem" tabindex="0">Item 2.1</li>
            <li role="treeitem" tabindex="0">Item 2.2</li>            
        </ul>
    </li>
    <li role="treeitem">Item 3</li>
</ul>

If you now check your ARIA-Widget again with inspect Objects through focusing “Item 2” you´ll see another misbehaviour:

Looking at the “Name”- and the “Description”-Row you can see, that the issues of the implemetion before are solved: The name only consists of the “Item 2” and the sub-Items are mapped correctly (“with 2”). The new issue is, that the treeitem has lost the reference to its siblings (“1 of 1”) – and that is, finally, the part where the WAI-ARIA role appears, which importance is not to underestimate: presentation. To bring back the treeitem to its siblings you have to “hide” the parent <li> element from being transported to the MSAA and this is exactly what the WAI-ARIA role presentation does as you can see in the documentation. The new widget code now looks like:

<ul role="tree">          
    <li role="treeitem" tabindex="0">Item 1</li>
    <li role="presentation">
        <span role="treeitem" tabindex="0">Item 2</span>
        <ul role="group" expanded="false">
            <li role="treeitem" tabindex="0">Item 2.1</li>
            <li role="treeitem" tabindex="0">Item 2.2</li>            
        </ul>
    </li>
    <li role="treeitem">Item 3</li>
</ul>

And the result is finally mapped correctly to the MSAA (“2 of 3” and “with 2”):

Using the WAI-ARIA role presentation can be a great help for building ARIA-Widgets out of a logical markup structure, e.g it would be no problem to include further elements, like links, in your list. You can find an progressive enhanced solution for building an accessible Tree View-Widget in the new version 0.9 of access.see.be.