Closed Bug 1579633 Opened 4 months ago Closed 3 months ago

The menu element should map to role=list


(Core :: Disability Access APIs, enhancement, P2)

68 Branch



Tracking Status
firefox71 --- fixed


(Reporter: scottaohara, Assigned: morgan)


(Blocks 1 open bug)


(Keywords: dev-doc-needed)


(2 files)

Attached file menu.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Steps to reproduce the problem:

  1. Open the provided reduced test case.
  2. Check accessibility mappings to verify that menu is not mapped as a list, though it should be a semantic alternative to the UL element.
  3. Attempting to navigate to the menu or its child list items with a screen reader will either not work, or the screen reader will try to expose each list item as a separate single item list, depending on the browser and screen reader pairing used.

Actual results:

The menu is not exposed as a list and thus it and the list items within cannot be consistently navigated to, if at all, when navigating by lists or list items when using a screen reader with Firefox.

Expected results:

Per the HTML specification: "The menu element is simply a semantic alternative to ul..."

Since the menu should be treated as a UL, and can contain LI elements, it should map similarly to a UL element to allow assistive technologies to navigate to understand & navigate to the element and the contained list items.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Probably just copy-paste this and change ul to menu?

Component: DOM: Core & HTML → Disability Access APIs

The HTML AAM doesn't contain a mapping for <menu>, even though it does for some other elements 9e.g. <li> and <a>) inside <menu>:
The <a>, etc. mappings are a bit worrying. If we map <menu> to list and <a> inside <menu> should be role button, now we'll have a list containing buttons instead of list items.

Also, I've seen several references to <menu> being semantically more like a "toolbar":

NoteThe menu element is simply a semantic alternative to ul to express an unordered list of commands (a "toolbar").

Either way, I think we need to get the mapping clarified here. Is it a toolbar or a list? If it's a list, what about <a>, etc. inside?

Blocks: htmla11y
Flags: needinfo?(scottaohara)
Priority: -- → P2

Hi James,
I have a PR ready to add a mapping for <menu> that matches the mapping expectations of this issue report. The only hold up I have is getting verification that browsers will implement the list mapping.

You and I are quoting the same note from the HTML specification, but per this thread and specifically this comment, it's pretty clear the expectation is that the element can be used by developers to create "toolbars", but there is no default behavior for the "toolbar".

Regarding your closing question about <a> elements within menus, would you please elaborate if the above doesn't help clarify? The content model for a menu expects only li, script or template children and there should be no altered mappings for buttons or links within the list items.

Flags: needinfo?(scottaohara)

Your PR clarifies things for me; you're removing the altered mappings for <a>, etc. inside <menu>. Thanks. We will implement this (but no ETA as to when at this stage).

Type: defect → enhancement
Ever confirmed: true

Great, thank you.

Simple test case:

The menu element should have a role of LIST. The li elements should have a role of LISTITEM. Same as mappings for ul and li elements. Comment 1 is probably correct as to what needs to happen here.

Note the menu test in accessible/tests/mochitest/elm/test_HTMLSpec.html is outdated; you can't have buttons as children of menu any more as per the spec. See the spec link in comment 0.

Assignee: nobody → mreschenberg
Pushed by
Update menu role, HTML spec tests. r=Jamie
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

I think the <menu type> attribute no longer exists - true?

If so, is it fine to completly remove it from MDN docs?

Keywords: dev-doc-needed

True. It's listed among the obsolete features in the HTML spec:

You need to log in before you can comment on or make changes to this bug.