Aria-practices: The solution for handling top-level menu items which are also hyperlinks?

[ianthedev]

As explained by @terrill in #145 (shortcut), it's a widely used approach to make navigation menu's top-level menu items not only trigger sub-menus on mouseover, but also serve as hyperlinks that link to top-level landing pages on click.

The said approach is very common and isn't showing any sign of going out of fashion, from what I can see.

The current example of navigation menubar, however, isn't addressing the hyperlink thing for AT and sighted keyboard users.

Could we please have an instruction on how to properly make AT and sighted keyboard users able to use top-level menu items' hyperlinks?

[patrickhlauke]

The solution is fairly simple: either stop doing that (don't actually make the top-level item a link, or provide a separate control to open/close the menu. See https://www.w3.org/WAI/tutorials/menus/flyout/

Additionally, I'd note that the ARIA menu pattern isn't really meant for navigation, but app-like menus (though this point seems to be disputed(. In that context, no native application menu behaves in a way where clicking on the menu's button (e.g. "File", "Edit", "View", etc.) triggers any kind of functionality.

[ianthedev]

@patrickhlauke I agree with you that the ARIA menu pattern is meant for app-like menus, not for navigation.

So it looks like the two navigation examples (the aforementioned one and the menu one) might be disputable.

[LaurenceRLewis]

If interested this is a good article by Bryan Garaventa of WhatSock and Level Access on native html and aria menus https://www.levelaccess.com/challenges-mega-menus-standard-menus-make-accessible/

[LaurenceRLewis]

I would not recommend the Fly-out Menu example given as it uses aria-haspopup which I don't recommend in this situation (Authors MUST ensure that the role of the element that serves as the container for the popup content is menu, listbox, tree, grid, or dialog). It it also broken because the aria-expanded is stuck on true. I built a menu based on the article menus article I posted and discussions I have had regarding accessible menus. Please note the website is my personal testing website, however, if you want to use the menu as is or change it to improve it, be my guest. Oh and it uses jQuery, sorry, but my JavaScript skills are urg :-)
https://www.a11ycats.com.au/m05_c01_p01.html

[ianthedev]

@Decrepidos Thanks. That makes sense.

Now I decide to avoid using role=menubar, role="menu", and aria-haspopup because those are apparently meant for application, not for navigation.

But in your example, I see the use of role="heading" as sub-menus' headings. I'm not sure if that's okay. If I understand correctly, headings are meant for identifying sectioning element such as section, article, nav, and aside.

Besides, it's fine to use jQuery, in my opinion, as vanilla code is often longer and more complicated.

[LaurenceRLewis]

@ian-y role heading and aria-level indicate the structural level of the menu. This helps screen reader users identify the nested menu levels—especially if there are multiple levels. Probably not needed when there is only one nested menu level. However, I tend to use role heading and aria- level after discussions with @accdc who recommended it. :-)

[ianthedev]

@Decrepidos I see. So some screen reader users prefer that.

I'm under an impression that screen reader users often navigate through headings to find interesting content more quickly. They can also bring up a dialogue box which is built-in in screen readers and contains all headings in a page.

Wouldn't it be tiresome for them to repetitively hear those same headings of navigation sub-menus from page to page?

[LaurenceRLewis]

Not from what I have been told. The person who recommended it is a totally blind screen reader user. 😬 Using JAWS for examples the Q key moves the screen reader to start reading from the main landmark. Then the H key can be used to skip through the content headings. So a screen reader user would not need to jump through the role headings in the menu for each page.

[ianthedev]

@Ian-Y I understand. Thank you for the information. :)

[LaurenceRLewis]

@Ian-Y Hi, if you're interested I updated the navigation to include optional the submenu expanding on mouseover. I also fixed a couple other minor bugs. https://www.a11ycats.com.au/m05_c01_p01.html

[ianthedev]

@Decrepidos Thank you. Because we haven't heard any word about this issue from W3C, I decide to just adopt the traditional "tab navigating" method for now. For sub-menus, I'm making them appear when the top-level lis receive any focus inside.

Although this method requires AT/keyboard users to navigate through all links inside nav one by one, it is the least confusing method I can think of now.

[LaurenceRLewis]

No problem. Good luck. 😬

[LaurenceRLewis]

@Ian-Y FYI Recent discussions with a blind screen reader user who is also an accessibility developer found ‘If role heading and aria-level is implemented, expanding the subsection it is a clear indicator that the section starts at a particular point, so the heading is helpful for that plus can quickly jump between them using the H and Shift+H keys with or without the sections being expanded, and even use the rotor on iOS to swipe between headings using single swipe up/down gestures.

[ianthedev]

@Decrepidos Thanks for the info. That is worth considering. Hopefully, the specification can advise on the viability of using sections and headings for navigational sub-lists so that developers are more confident in implementing it.

[stes-acc]

I think a new ARIA menu role property aria-menutype="navigationmenu" / aria-menutype="navigationmenuitem" as indicator that this menu is a hierachical list of links could ease the pain.

To do it role-wise we could have alternatively role="navigationmenu" and role="navigationmenuitem".

We could even do this already today using respective aria-roledescription strings for menu and menuitem role.

Still authors have to implement arrow key navigation and menu open triggering as for app menus.

With this we could indeed have menus consisting of links and looking like classic application menus. We do see this frequently in Joomla menu components, for example.

Thoughts?

[patrickhlauke]

i'd caution that it's not as easy as just inventing a new role="..." attribute. these need to match up (at least conceptually) with roles that browsers can expose via accessibility APIs, and that can then be understood by AT consuming them...

[stes-acc]

Well there is also https://github.com/w3c/aria-practices/issues/159 gracefully stating "hey, there is no problem using menu and menuitem roles also for pure navigation menus". If so, then ARIA Specifications should mention this usage explicitly. And if so, parts of this issue render absolutely obsolete.

The real challenge then is that menu-like structures using hyperlinks are then FORBIDDEN because there is no role counterpart. But they are out there....