WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Tree Navigation?

for

From: Birkir R. Gunnarsson
Date: Oct 26, 2018 2:36PM

If you want to implement a tree widget you must script the enire
keyboard interaction.
The element with the tree role should have the accessible name/label
and be the element that receives focus if user navigates with the
arrow keys.
The entire tree should be a single tab stop.
Again, read the ARIA Authoring Practices documentation for a tree
widget carefully. I believe it has a working example. If so, use that
example and copy all the script and ARIA roles exactly, that example
is the closest you get to an accessibility vetted tree.
Keep in mind that assistive technology applications are under no
obligation to support ARIA, even valid ARIA support for tree widgets,
even official ones, may vary. Make sure to test.
I'd be happy to help but afull exploration of your code will take me a
couple of hours and I am just absolutely slammed with work right now.



On 10/26/18, Wolfgang Berndorfer < <EMAIL REMOVED> > wrote:
> I agree to Birkirs arguments to avoid such nested navigation widgets as an
> issue for screen reader *usability*. (Hope I interpreted Birkir correctly.)
>
> But some like or need tree-navigation. And for those I ask:
> Are any ARIA tree-roles necessary at all in a with HTML well formed nested
> UL & LI construction? Screen readers can technically detect lists and
> levels
> there anyway.
>
> Wolfgang
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum [mailto: <EMAIL REMOVED> ] Im Auftrag
> von Birkir R. Gunnarsson
> Gesendet: Freitag, 26. Oktober 2018 17:54
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] Accessible Tree Navigation?
>
> Mike
>
> First of, my general experience is that using trees and menus is a lot
> of coding for developers and confusing for users.
> If you canfit your paradigm into a simple disclosure/accordion pattern
> you often save yourself a lot of head aches and your users too.
>
> <button id="x" aria-expanded="false">Menu x</button>
> <<div role="group" aria-labelledby="x" class="hidden"> <!-- this is
> the group of elements displayed user clicks the button>
> <ul>
> <li><a href="#">Link 1</a></li>
> ...
> </ul>
> </div>
> (the list construct is optional).
>
> When user clicks the button its aria-expanded attribute is set to
> "true" and the group is displayed.
>
> You can have the menu close when user moves focus out of it, as long
> as you set the trigger button's aria-expanded back to false.
> I the menu has a submenu you can use the same approach.
>
> This approach doesn't require juggling multiple ARIA attributes and
> writing JavaScript to manage keyboard focus.
>
> If you still need to do that consult the ARIA Authoring Practices spec
> https://www.w3.org/TR/wai-aria-practices-1.1/
> it is the ultimate/best guide for designing these widgets.
> In section 3 explore either the menu button or the tree widget.
> HTH
> -B
>
>
> On 10/26/18, Henry, Michael (IntelliDyne) < <EMAIL REMOVED> >
> wrote:
>> Hello, all.
>>
>> I hope this isn't too rudimentary of a question, but I've been trying to
>> unravel how to properly use ARIA to make a left navigation (structured
> like
>> tree navigation) accessible via keyboard.
>>
>> The more I read, though, the more turned around I get. Seems like every
>> article I read uses a slightly different approach or different ARIA
>> attributes, and none of them describe the exactly situation (markup
>> structure) that we have. Hopefully you guys can help?
>>
>>
>> Here's the basic structure of our navigation tree with my best current
> guess
>> at appropriate use of ARIA:
>>
>> <h2 ID="tree_label" class="visiblyHidden">Submenu for current
>> section</h2>
>> <ul class="LV1" role="tree" aria-labelledby="tree_label">
>> <li class="hasChildren">
>> <div role="treeitem" aria-selected="true | false"
>> aria-expanded="true | false" tabindex="0 | -1" >
>> <span class="icon" role="button"
>> onclick=""></span> [clicking here toggles the submenu open/closed]
>> <a href="/Plans/Eligibility">Eligibility</a>
>> </div>
>> <ul role="group" class="LV2" >…</ul>
>> </li>
>> </ul>
>>
>> I'm afraid I'm so confused on this that I don't know exactly what to ask.
>> But I think what I need to know is:
>> 1) should the <li> or the <div> have the role of "treeitem"?
>> 2) should the <li> or the <div> have the ARIA attributes?
>> 3) should all elements that we intend to make focusable (including the
>> <span.icon>, which expands/collapses the child <ul>) receive tabindex=-1
>> (making them part of the Roving Tabindex)?
>> 4) should it be the first Root Node ("Eligibility" in this example) that
>> should have tabindex=0 on page load?
>> 5) where is the appropriate place for the "aria-selected" attribute?
>> 6) where is the appropriate place for the "aria-expanded" attribute?
>>
>> Thank you so much for any help.
>> Mike
>>
>>
>> ---
>> Mike S. Henry
>> Creative Services Lead
>> IntelliDyne Contract Employee
>> Supporting Enterprise Infrastructure (formerly Military Health System
>> Cyberinfrastructure Services - MCiS)
>> Desk: (703) 882-3962
>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
> > > > >


--
Work hard. Have fun. Make history.