Joomla 4 Admin menu

[zwiastunsw]

Ciaran Walsh asks for tests and comments on the pen for new sidebar.
You can submit your comments immediately to
joomla/40-backend-template#365
or
If you want to discuss them first in the Joomla Accessibility Team, report them to this topic.

[zwiastunsw]

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

• The Toggle Menu switch is not a link. Use the semantic button tag here.
• If the "plus" icons are to be used as switches (open the submenus), they must also be tagged with a 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 submenu
• aria-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.

[brianteeman]

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

[zwiastunsw]

I am thinking of all the elements of li that contain the element a

[brianteeman]

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

[zwiastunsw]

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 ! :).

[chmst]

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.

[brianteeman]

The benefit of the role being on the ul is that it will simplify and reduce the markup.

[zwiastunsw]

@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.

[zwiastunsw]

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.

• Enter, Space: Activate the currently focused menu item or expand it, if it has a submenu and moves focus to first item in the submenu
• Arrows: up, down, left, right: moves the keyboard focus through menu items
  -- Right Arrow: moves focus to the right adjacent submenu, expand currently focused collapsed menu item, collapsed the previous menu, if it was expanded. If focus is on the last item, moves focus to the first item in this menu.
  -- Left Arrow: moves focus to the left adjacent submenu, expand currently focused collapsed menu item, collapsed the previous menu, if it was expanded. If focus is on the first item, moves focus to the next item in this menu or submenu.
  -- Down Arrow: moves focus down in the currently menu or submenu. If focus is on the last item, moves focus to the first item in this menu or submenu.
  -- Up Arrow: moves focus up in the currently menu or submenu. If focus is on the first item, moves focus to the next item in this menu or submenu.
• Home: Moves focus to first item in the menu / submenu.
• End: Moves focus to last item in the menu / submenu.
• Escape: Collapse the currently focused menu or submenu and returns focus to the parent menu item.
• Tab: collapse menu and focus moves to next control on page (to the next active item on the page)

About managing focus within components using a roving tabindex see WAI-ARIA practices.

Note
I corrected this description after @DGT41 remark (below).

[brianteeman]

agreed

[dgrammatiko]

Part two I guess is for me...

[dgrammatiko]

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...

[zwiastunsw]

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.

[ciar4n]

Thank you @zwiastunsw

I have updated the pen as per your suggestions (#35 (comment))

https://codepen.io/littlesnippets/pen/4d7312648363235a6b1c9ed9a8df64cf

[zwiastunsw]

@DGT41 : I corrected description keyboard behavior after your comment.

[zwiastunsw]

This is the third part of my comments. Screen readers interaction:
The screen reader should announce:

• the name of the navigation menu (label). Add a menu label to the nav tag, using aria-label or aria-labelledby.
• the number of links in the menu/submenu. If the menu structure is correct, the screen reader automatically reads the number of items in the list.
• the name of each menu item. If you use graphic icons as links, make sure you have a label accessible (using aria-label). Hide the icon from screen readers (use aria-hidden).
• that the menu item contains a submenu. Use aria-haspopup to announce it.
• that the submenu is expanded or not. Use 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.

[brianteeman]

the first three all seem to be done

[zwiastunsw]

@brianteeman : Yes!
I added this comment so that everything would be in one place.

[dgrammatiko]

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:

• the close button needs to be the first a tag in the li element
• the plus icon needs to be inside another li element after the first one.

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.