E-mail List Archives
Thread: Accessible Tree Navigation?
Number of posts in this thread: 8 (In chronological order)
From: Henry, Michael (IntelliDyne)
Date: Fri, Oct 26 2018 8:31AM
Subject: Accessible Tree Navigation?
No previous message | Next message →
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
From: Birkir R. Gunnarsson
Date: Fri, Oct 26 2018 9:53AM
Subject: Re: Accessible Tree Navigation?
← Previous message | Next message →
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 ADDRESS 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.
From: Henry, Michael (IntelliDyne)
Date: Fri, Oct 26 2018 11:50AM
Subject: Re: Accessible Tree Navigation?
← Previous message | Next message →
Thanks, Birkir.
Unfortunately, our markup is not going to change, but I will try again to digest the spec. It's pretty far outside my wheel house.
What I did gather, though, is that the "aria-expanded" attribute ought to be on the <span.icon>, which serves as the trigger to expand/collapse the sub menu?
- mh
---
Mike S. Henry
Creative Services Lead
IntelliDyne Contract Employee
Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
Desk: (703) 882-3962
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = >
Sent: Friday, October 26, 2018 11:53:47 AM
To: WebAIM Discussion List
Subject: 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 ADDRESS 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.
From: Wolfgang Berndorfer
Date: Fri, Oct 26 2018 1:49PM
Subject: Re: Accessible Tree Navigation?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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.
From: Birkir R. Gunnarsson
Date: Fri, Oct 26 2018 2:36PM
Subject: Re: Accessible Tree Navigation?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
From: glen walker
Date: Fri, Oct 26 2018 3:03PM
Subject: Re: Accessible Tree Navigation?
← Previous message | Next message →
Going back to Mike's original question on the location of the ARIA
properties for a tree, you started off correctly by specifying role="tree"
on the <ul>, but once you change the semantics of a list, you also have to
change the semantics of all the list children (<li>), otherwise you'll have
invalid HTML with <li> items without a parenting <ul> item. So your
role="treeitem" should be on the <li> elements and not the <div> under the
<li>.
Since it's the treeitem itself (<li>) that will be expanded, the
aria-expanded should also be set on the <li>.
Same with aria-selected, set it on the <li>/treeitem.
As Birkir mentioned, the authoring practice has a decent example of a tree.
https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-1/treeview-1a.html
The example is not being used for navigation so it's not going to use
aria-selected to indicate the currently selected node. But in your case,
if the navigation tree is always shown and you have a visual indicator on
the tree as to what page is selected, then you'd want aria-selected.
Glen
From: Jonathan Avila
Date: Fri, Oct 26 2018 4:10PM
Subject: Re: Accessible Tree Navigation?
← Previous message | Next message →
We also have a blog post on creating accessible tree controls with a codepen example
https://www.levelaccess.com/creating-an-accessible-aria-tree-control/
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Friday, October 26, 2018 5:03 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessible Tree Navigation?
Going back to Mike's original question on the location of the ARIA properties for a tree, you started off correctly by specifying role="tree"
on the <ul>, but once you change the semantics of a list, you also have to change the semantics of all the list children (<li>), otherwise you'll have invalid HTML with <li> items without a parenting <ul> item. So your role="treeitem" should be on the <li> elements and not the <div> under the <li>.
Since it's the treeitem itself (<li>) that will be expanded, the aria-expanded should also be set on the <li>.
Same with aria-selected, set it on the <li>/treeitem.
As Birkir mentioned, the authoring practice has a decent example of a tree.
https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-1/treeview-1a.html
The example is not being used for navigation so it's not going to use aria-selected to indicate the currently selected node. But in your case, if the navigation tree is always shown and you have a visual indicator on the tree as to what page is selected, then you'd want aria-selected.
Glen
From: Henry, Michael (IntelliDyne)
Date: Tue, Oct 30 2018 6:42AM
Subject: Re: Accessible Tree Navigation?
← Previous message | No next message
Thanks for the helpful tips, everyone!
---
Mike S. Henry
Creative Services Lead
IntelliDyne Contract Employee
Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
Desk: (703) 882-3962