ARIA role="menuitem" for <a> or <li>

Question

I've found two possible solutions:

1. apply role="menuitem" for the <li> tags:

   <li role="menuitem"><a ...>some menuitem</a></li>

2. apply role="menuitem" for the <a> tags:

   <li role="presentation"><a role="menuitem" ...>some menuitem</a></li>

I think that the second solution is the logical one, but I am unsure. And I cannot use it in a more complex situation, only 2, because the submenuitems are not children of the <a> tag:

<li role="menuitem"><a ...>some menuitem</a></li>
<li role="menuitem" aria-haspopup="true">
  <a ...>some menuitem with children </a>
  <div><ul>
    <li role="menuitem"><a ...>submenuitem</a></li>
    ...
  </ul></div>
</li>

Is it correct? Is there some additional possible improvement on it?

The HTML structure is defined by the framework I use, I am not able to change it.

Answer 1

Answer to Question Asked

If you are genuinely applying an operating-system-style menu to an application, then you want to put the role on the <a>. That is the item that performs the function of the menu item (linking to another view or page or state).

So your second suggestion is correct:

<li role="presentation"><a role="menuitem" ...>some menuitem</a></li>

Curveball

Now that being said, I suspect that you do not really want an operating-system-style menu. To see what is expected of one, take a look at the WAI-ARIA Authoring Practices item 2.14 Menu or Menu bar.

By invoking this kind of menu, you are telling a skilled user of a screen reader that it will behave just as an operating system menu, which means you need to honor the keyboard commands below (so you have to code them all, ARIA does not just make a browser honor them).

Instead, consider just using a <nav> element to hold your list (which will be announced to screen readers and act as a landmark for in-page navigation), keep the list semantics in place (IOW, do not use role=presentation as you want users of screen readers to know how many items there are), and style it to visually appear as you see fit.

This way you are not creating a worse experience for screen reader users in your effort to help them (or satisfy a checklist item).

ARIA Menu Keyboard Interaction

• When a menu opens, or when a menubar receives focus, keyboard focus is placed on the first item. All items are focusable as described in 4.6 Keyboard Navigation Inside Components.
• Enter:
  • When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item.
  • Otherwise, activates the item and closes the menu.
• Space:
  • When focus is on a menuitemcheckbox, changes the state without closing the menu.
  • When focus is on a menuitemradio that is not checked, without closing the menu, checks the focused menuitemradio and unchecks any other checked menuitemradio element in the same group.
  • (Optional): When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item.
  • (Optional): When focus is on a menuitem that does not have a submenu, activates the menuitem and closes the menu.
• Down Arrow:
  • When focus is on a menuitem in a menubar, opens its submenu and places focus on the first item in the submenu.
  • When focus is in a menu, moves focus to the next item, optionally wrapping from the last to the first.
• Up Arrow:
  • When focus is in a menu, moves focus to the previous item, optionally wrapping from the first to the last.
  • When focus is in a menubar, does nothing.
• Right Arrow:
  • When focus is in a menubar, moves focus to the next item, optionally wrapping from the last to the first.
  • When focus is in a menu and on a menuitem that has a submenu, opens the submenu and places focus on its first item.
  • When focus is in a menu and on an item that does not have a submenu, performs the following 3 actions:
    1. Closes the submenu and any parent menus.
    2. Moves focus to the next menuitem in the menubar.
    3. Either: (Recommended) opens the submenu of that menuitem without moving focus into the submenu, or opens the submenu of that menuitem and places focus on the first item in the submenu.
    Note that if the menubar were not present, e.g., the menus were opened from a menubutton, Right Arrow would not do anything when focus is on an item that does not have a submenu.
• Left Arrow:
  • When focus is in a menubar, moves focus to the previous item, optionally wrapping from the last to the first.
  • When focus is in a submenu of an item in a menu, closes the submenu and returns focus to the parent menuitem.
  • When focus is in a submenu of an item in a menubar, performs the following 3 actions:
    1. Closes the submenu.
    2. Moves focus to the previous menuitem in the menubar.
    3. Either: (Recommended) opens the submenu of that menuitem without moving focus into the submenu, or opens the submenu of that menuitem and places focus on the first item in the submenu.
• Home: If arrow key wrapping is not supported, moves focus to the first item in the current menu or menubar.
• End: If arrow key wrapping is not supported, moves focus to the last item in the current menu or menubar.
• Any key that corresponds to a printable character (Optional): Move focus to the next menu item in the current menu whose label begins with that printable character.
• Escape: Close the menu that contains focus and return focus to the element or context, e.g., menu button or parent menuitem, from which the menu was opened.
• Tab: Moves focus to the next element in the tab sequence, and if the item that had focus is not in a menubar, closes its menu and all open parent menu containers.
• Shift + Tab: Moves focus to the previous element in the tab sequence, and if the item that had focus is not in a menubar, closes its menu and all open parent menu containers.