menubar/menulist/menuitem content model

[davidsgrogan]

This is a rough proposal for a content model for the menubar/menulist proposal (explainer).

In response to a content model violation, we are cribbing from #1099 and customizable select behavior:

• We'll still render the violating elements
• We'll emit devtools console messages warning the author
• If the content model is violated inside a menubar, we will give the menubar the ??? aria role
• If the content model is violated inside a menulist, we will give the menulist the dialog aria role

Content Model

<menubar>

<menubar> represents an in-page group of <menuitem> elements.

• Allowed Descendants:
  • <menuitem>
• Forbidden: Any other element

<menulist>

<menulist> represents a native popover containing a list of <menuitem> elements.

• Allowed Descendants:
  • <menuitem>
  • <fieldset> (used for grouping checkable items)
  • <hr> (used as a separator)
• Forbidden: Any other element

<menuitem>

The <menuitem> element represents an individual command or submenu trigger.

• Allowed Descendants
  • <div>
  • phrasing content (e.g., text, <span>, <img>), provided it is not in the exclusion list below.
• Exclusion List
  • <datalist>
  • <object>
  • interactive content (e.g., <a>, <button>, <input>, <textarea>, <select>).
  • Any element with a tabindex attribute specified
  • Any element that is contenteditable
• Forbidden: Any other element

(Some) open questions:

1. What aria role do we use for a menubar with prohibited descendants?
2. Should we allow divs inside menubar and menulist to wrap menuitems?

We've started to write this content model at https://whatpr.org/html/12011/interactive-elements.html#the-menubar-element

[lukewarlow]

Should we allow legend inside of menubar and probably menulist to give them an accessible name?

[scottaohara]

Yeah, to align with what aria allows, there shouldn’t be a difference in content model with menulist and menubar. They should both allow fieldset as a child, which would then allow legend and menuitems

Definitely not as common for a menubar to have visually labeled groups, but again, it’d be weird to not maintain parity with aria allowances.

[scottaohara]

Re open questions…

One of the reasons that the listbox role mutates is because in testing we noticed that options would still be exposed correctly by at least windows screen readers. Has that been tested for menuitems yet?

I personally don’t think the menubar role needs to change.

Divs should be fine, so long as they are used for styling and remain ignored in the a11y tree. (Eg, no tabindex or other attributes that would make them show up in the a11y tree).

[lukewarlow]

I meant as a direct child, just thinking because toolbar will allow direct legend so wondered if menubar should.

[josepharhar]

Yeah, to align with what aria allows, there shouldn’t be a difference in content model with menulist and menubar. They should both allow fieldset as a child, which would then allow legend and menuitems

Sounds good, this makes things a bit simpler!

One of the reasons that the listbox role mutates is because in testing we noticed that options would still be exposed correctly by at least windows screen readers. Has that been tested for menuitems yet?

Are you talking about how we made the select element's popup change its role from listbox to dialog? I actually didn't know this and was wondering how that could have worked, but this makes sense. I certainly havent tested menuitems in a dialog - how did you determine that options were "exposed correctly" in this case?

I personally don’t think the menubar role needs to change.

Great, that makes things simpler.

Divs should be fine, so long as they are used for styling and remain ignored in the a11y tree. (Eg, no tabindex or other attributes that would make them show up in the a11y tree).

Great, yeah I think this is probably good for authors and matches customizable select.

[josepharhar]

@scottaohara do you think that we won't need to change the role from menu to dialog in any case? If we tested this out, what might we look for exactly to determine whether we should or shouldn't?

[css-meeting-bot]

The Open UI Community Group just discussed menubar/menulist/menuitem content model, and agreed to the following:

• RESOLVED: change a11y mapping of menulist element from menu to dialog when there are non-menuitem interactive elements and make additional changes to menuitems to make them work better in dialogs, such as adding posinset to the menuitems and adding a role description to the dialog-mapped menu. defer to ariawg on this behavior. perhaps also add more

The full IRC log of that discussion

<masonf> q+
<jarhar> q+
<masonf> ack masonf
<masonf> ack jarhar
<dgrogan> q+
<masonf> ack dgrogan
<jarhar> proposed resolution: change a11y mapping of menulist element from menu to dialog when there are non-menuitem interactive elements and make additional changes to menuitems to make them work better in dialogs, such as adding posinset to the menuitems
<jarhar> proposed resolution: change a11y mapping of menulist element from menu to dialog when there are non-menuitem interactive elements and make additional changes to menuitems to make them work better in dialogs, such as adding posinset to the menuitems. perhaps also add more fixes to options in a dialog for customizable select.
<jarhar> proposed resolution: change a11y mapping of menulist element from menu to dialog when there are non-menuitem interactive elements and make additional changes to menuitems to make them work better in dialogs, such as adding posinset to the menuitems and adding a role description to the dialog-mapped menu. defer to ariawg on this behavior. perhaps
<jarhar> also add more fixes to options in a dialog for customizable select.
<masonf> +1
<scott> +1
<Jacques> q+
<masonf> ack jacques
<Jacques> +1
<dbaron> maybe s/when there are/when the content model is violated by/
<jarhar> RESOLVED: change a11y mapping of menulist element from menu to dialog when there are non-menuitem interactive elements and make additional changes to menuitems to make them work better in dialogs, such as adding posinset to the menuitems and adding a role description to the dialog-mapped menu. defer to ariawg on this behavior. perhaps also add more
<jarhar> fixes to options in a dialog for customizable select. do not change the role for menubar elements with non-menuitem interactive descendants.

[mfreed7]

The Open UI Community Group just discussed menubar/menulist/menuitem content model, and agreed to the following:

Actual meeting notes are here: https://docs.google.com/document/d/1mHzKRTGk6bs7uHN9Y3HuN3mT-XFd7mBP7tLlWNPnyOs/edit?tab=t.srm6ztuhp2gh