Open zwiastunsw opened 6 years ago
This is the first part of my comments.
1. Use the nav
tag for the menu container
This is the navigation menu. Use the nav
tag as a container and not as a div
element with a "navigation" role. The nav
element has a core navigation role.
suggestion: Update this line for:
<nav class="mainnav-container" aria-label="Admin menu">
2. Don't use ARIA menu semantics in navigation menus ARIA menus are not designated for navigation but for application behavior.
role="menuitem"
for the li element is incorrect and unnecessary.
Incorrect because: The li
element is not a link, this is part of the list. A menu item is a
element.
Not necessary because: The a
element is recognized as a link.
Since the li
element does not play its core role here, it can be assigned a role="presentation"
.
suggestion: Add to all elements li
the attribute role="presentation"
or role="none"
role="menu"
for the ul
element is unnecessary. Using the ul
tag gives you sufficient information that you have a list of menu items.
Note: This is not an error. In the Navigation Menubar Example authors WAI-ARIA practices use menu semantics, include role="menu"
, role="menubar"
.
suggestion: remove the role="menu"
from all ul elements.
3. Use semantics tag
button
tag here.button
.4. ARIA markup In the horizontal mega menu, the new website of the Accessiblility Initiative uses only the following ARIA markup:
aria-label="Main"
: for element <nav>
to identify a menu role="presentation"
: for element <li>
aria-haspopup="true"
: for element <a ...>
with submenu, to indicate that a menu item has a submenuaria-expanded="true"
or aria-expanded="false"
: for <a ...>
with submenu to indicate whether the submenu is expanded or not (this state is modified by the script).My proposal: Use this simple marking and then, if necessary, progressively improve it.
I agree with all of this - just one part I don't understand
Since the li element does not play its core role here, it can be assigned a role="presentation".
Do you mean all li elements or just the top level li elements eg Users, Menus, Content etc
I am thinking of all the elements of li
that contain the element a
reading this http://csskarma.com/blog/difference-rolepresentation-aria-hiddentrue/
<ul role="presentation">
<li>This is an item</li>
<li>I like a good<a href="#!"sandwich</a></li>
<li>Hello last item</li>
</ul>
will be seen in the DOM as
<span role="presentation">
<span>This is an item</span>
<span>I like a good <a href="#!"sandwich</a></span>
<span>Hello last item</span>
</span>
So I n ow understand why you chose role=presentation but shouldnt it be on the UL and not on every LI
The 'ul' element says we have a list of elements. But the elements in this list are not 'li' but 'a'. Therefore, we remove the core role from the 'li' element, and not from the 'ul'. See source code in menu in the horizontal mega menu, the new website of the Accessiblility Initiative
Thank you for the link ! :).
I think it is not necessary to see the 'ul', Whether it is a list or not is not important or is it? But it should not make a difference for a11y.
The benefit of the role being on the ul is that it will simplify and reduce the markup.
@chmst You are right. This is not very important. But he is. The screen reader will announce for ex. Naivgation landmark list 6 items. But I'm still going to test it with a screen reader.
This is the two part of my comments. Keyboard interaction
Since the navigation menu is a set of links, the user can navigate through the menu items using the tab key. This is not a good solution, however, because users have to use the tab to access all menu items in order to get to the next active item on the page.
In DHTML Style Guide Working Group was proposed the keyboard model, which was adapted in the WAI-ARIA Authoring Practices. Specifically, this guidance limits the role of the tab key to entering and existing the menu. In this model, once the menu has focus, the arrow keys, not tab, are used to navigate between top-level menu items.
About managing focus within components using a roving tabindex see WAI-ARIA practices.
Note I corrected this description after @dgt41 remark (below).
agreed
Part two I guess is for me...
Down Arrow performs as Right Arrow is described above, and vice versa. Up Arrow performs as Left Arrow is described above, and vice versa.
Ok just out of curiosity why this is changing depending on the layout? I mean for visual impaired people the actual view of the page is less important than the arrow keys. Unless I'm missing something...
I mean for visual impaired people the actual view of the page is less important than the arrow keys. Unless I'm missing something...
It is not only people with visual impairments who use the keyboard. Also people who cannot use a mouse.
Thank you @zwiastunsw
I have updated the pen as per your suggestions (https://github.com/joomla/accessibility/issues/35#issuecomment-373691332)
https://codepen.io/littlesnippets/pen/4d7312648363235a6b1c9ed9a8df64cf
@dgt41 : I corrected description keyboard behavior after your comment.
This is the third part of my comments. Screen readers interaction: The screen reader should announce:
nav
tag, using aria-label
or aria-labelledby
.aria-label
). Hide the icon from screen readers (use aria-hidden
).aria-expanded
to announce it. Use Javascript to dynamically change information about the expanded state submenu.
Use aria-hidden
carefully. For example, do not hide the submenu nested list, because the screen reader will not know that there is a submenu.
the first three all seem to be done
@brianteeman : Yes! I added this comment so that everything would be in one place.
So we have a new codepen https://codepen.io/dgt41/pen/jzLGaG with the (early) functionality in place. At the moment we're stuck because the html markup needs to change again. The problems are:
Then we still have to patch correctly the close function and any other bugs that are still there. But this menu now is based on the code from W3C (we are allowed to use it, I checked with @brianteeman) so in theory we should be in the right track.
Ciaran Walsh asks for tests and comments on the pen for new sidebar. You can submit your comments immediately to https://github.com/joomla/40-backend-template/issues/365 or If you want to discuss them first in the Joomla Accessibility Team, report them to this topic.