[menu] - do we *need* to introduce menuitem elements?

@domfarolino

During yesterday's telecon, @domfarolino had a very interesting comment at the end concerning the discussion of how to handle menuitems that behaved as hyperlinks, overtly declaring he was opposed to allowing href on menuitem elements. The brief details seemed related to parsing/security (please correct me if i misunderstood). But that less than a minute mention gave a lot of context to why we kept having to retread the questions about why hyperlinks shouldn't be nested inside of menuitems. That got me thinking...

If href being an allowed attribute to menuitem is a no go...
And nesting hyperlinks within menuitem elements is also a no go. (in case it wasn't clear - i'm very much opposed to that as well. it flys in the face of ARIA and HTML best practices - that is except for the summary element which is an example of HTML contradictions and i will stop myself before i rant... )
That means both of those options are a waste of time to discuss further.

That got me wondering about how to allow instances of menuitems that do need to be able to act as a hyperlink, but shouldn't need to have authors use JavaScript when there is already a native way to markup hyperlinks.

I assume it's not just href - but any attribute that would for a URL as its value is a non-starter. Additionally, it wouldn't even just need to be href, but other hyperlink attributes that would be needed for menuitem as well. target, download, maybe others. I understand the complexity this would add, for what did seem such a simple solution when not considering the bigger picture.

So what if we just allowed hyperlinks as children of menulists? As we briefly touched on yesterday, that'd be quite odd - especially if a menu contained both menuitems and hyperlinks. It'd be strange to introduce the new elements and then be like - oh but for this use case, use this very old element instead.... but that got me wondering more..

skip all the preamble, here's the proposal

What if we drop the idea of adding menuitem elements in this proposal, and instead just use <a href> and <button> elements (which would default to type=button when a child of a menulist/bar.

The rational here being that this is not actually dissimilar to what some people are doing now to create custom ARIA menus.

<div role=menu>
  <button role=menuitem ...>foo</button>
  <a href=lol.html role=menuitem ...>bar</a>
</div>

The key difference here would be that the browser would automatically handle the implicit roles of the a and button elements - converting them to role=menuitem in the accessibility tree.

While there should be some unification in the UA styling of these elements when used in this context, arguably they could have some visual distinctions to help indicate one will perform an action (button) and one will likely navigate you somewhere (hyperlink).
These elements could then reuse their default high contrast styling - as they have coloring variations to help high contrast theme users know the difference - rather than needing to repeat or create new styles for menuitem.

This doesn't necessarily solve for everything we we've been discussing. But maybe it can help with the differentiation of when an item is really meant to be a hyperlink vs action. It does also mean there's one less element to need to propose - particularly one that uniquely comes with interesting history and truly, would technically be performing redundant functions to the existing hyperlink and button elements...

looking forward to hear thoughts on this here or when we can talk about this during an upcoming meeting.

I quite like this idea. It would make implementation simpler in some ways, e.g. no need to make command/commandfor work on a new element.

A couple of questions that come to mind:

How do we handle menuitem checkbox and radio?
How do we handle the different activation behaviours (that is assuming I'm correct in thinking menuitem is different to buttons and links)?
- I'm guessing this can probably just be by virtue of them being children of menulist/menubar.

At the very least I do think just allowing anchors as children is a good idea and alleviates the concerns around putting anchor inside menuitem as well as making menuitem a new type of link but only some of the time.

i don't see any reason why the checkbox/radio scenario wouldn't be as we already specified - save for the fact that only buttons would be allowed to be used in this context. This sort of doubles down on the need to use the parent container as the indicator as to whether they'd be single select or multiple.

re: the different action behaviors - we can and should discuss this further. they could potentially be unified in this context, or aspects of them could remain different (to try to handle some of the ux issues with the navigation menu pattern taht we touched on yesterday)

re: your last bullet - that was my thought.

but yeh....still noodling on this.

One other thought experiment that might be useful. Do buttons have functionality that we wouldn't want here?

E.g. do we want to support interesttarget on a "menuitem". Perhaps we can disable specific functionality in this context. But how much of that we do might impact whether it makes sense to be a button or a new element.

great point. IMO, interesttarget (tooltips) on "menuitems" is a sign of a poor design. i've yet to see an instance of a well formed menu that needed tooltips. for the cases that i have seen where tooltips were used on menuitems - it was because the overall design / understandability of the UI and what the actions the menuitems were to perform was piss poor - to put it nicely.

i'm sure someone could come up with a creative and valid use case though. i'd love to see it. i don't usually get to see things like that.... i generally spend my time dealing with the bad UI people make (even if it "looks" pretty...)

@scottaohara

We talked about this internally, and we do like the proposal; specifically I think it solves the anchor/link discoverability problem for accessibility technology pretty neatly, which is nice. One tradeoff we lean towards is not allowing normal <button>s to be nested in <menulist>s, and instead stick with the new <menuitem> element and its <fieldset>/checkability machinery. Something new feels easier to integrate with the menu-specific use case, instead of stripping down and overwriting certain parts of the existing button processing model in a way that feels a little magical just because it happens to appear inside a menu. There are further complexities with <button> and its default appearance, and overall I think a lot of the complexity can be side-stepped with the middle ground of indeed allowing anchors inside menulists, and allowing menuitems as well.

One remaining accessibility issue that is not immediately worked out by this proposal is what we discussed on the last telecom about "dual accessibility roles", right? My understanding is that if you're using accessibility technology in application mode, and you come across a <menulist> with anchor tags in it that's intended to be a navigation menubar, if we don't make the menu's role "navigation", then AT may skip over the whole menu when looking for navigation-related components. So while this fixes the anchor tag discoverability issue, I think we still need to tread lightly and figure out how to ensure a menu with anchor links in it doesn't continue to have the wrong role. @scottaohara let me know if my understanding of this issue is sound.

/cc @dizhang168 @mfreed7 @josepharhar

I think it solves the anchor/link discoverability problem for accessibility technology pretty neatly

this proposal doesn't actually work out this problem (though not to say it couldn't be part of exposing a dual a11y role - if that ends up being the way ARIA considers doing something like this).

the intent was to use button elements and hyperlinks but their role would still become role=menuitem.

this was trying to address the fact there was opposition to using href on a new menuitem element, and that we didn't seem to have a good pathway forward.

per your response above, i'm not sure there's any good pathway forward with this proposal?

One thing I quite like with using buttons is that it does quite neatly match the authoring of an eventual <toolbar> element.

In that you'd do

<toolbar>
 <button command=...>
</toolbar>

If you could likewise do the same for menubar then as an author it seems pretty clean?

<menubar>
 <button command=...>
</menubar>

The fact that browser exposes this with a menuitem role seems inconsequential to me as an author.

reasons i dont like reusing <button>:

have to deal with button's appearance:auto rendering (the new menuitem element could just not support the appearance property which would be great)
have to undo button's type and type-related activation behavior when its inside a menu
have to add checked pseudo class or something to make them checkable, also ::checkbox pseudo element, which only makes sense when buttons are inside a fieldset inside a menulist

The Open UI Community Group just discussed [menu] Define a default checked attribute for menuitem, and agreed to the following:

RESOLVED: keep introducing <menuitem> element, instead of using buttons. Table the discussion about anchor children for #1193 where we'll continue to discuss the navigation menubar use case

The full IRC log of that discussion

<domfarolino> q+
<gregwhitworth> lwarlow: this is scott4 issue but I'll summarize
<gregwhitworth> lwarlow: do we need a <menuitem> element at all
<gregwhitworth> lwarlow: can we use button and anchor element to do that?
<dbaron> github: https://github.com//issues/1200
<dbaron> s/Define a default checked attribute for menuitem/do we *need* to introduce menuitem elements?/
<gregwhitworth> lwarlow: rather than having a new element and add the href attribute and other stuff, we won't want to do that; command and commandfor are for button elements is that we want that to work for menuitems do we need a new element or can we use buttons and anchors and the browser sees they're children and does the correct accessibility
<gregwhitworth> scott4: yeah, that's the gist of what I was going over. Last week's call was objecting to href and that's where I realized maybe we re-use the buttons and hyperlinks and we have everything we need
<gregwhitworth> q?
<gregwhitworth> ack domfarolino
<gregwhitworth> domfarolino: I see the issue as having two parts
<gregwhitworth> domfarolino: how do we accomodate the menubar navigation case and have reasons for having href on menuitem
<gregwhitworth> domfarolino: the AT gives them all hrefs on the page but it's not aware of menuitem
<gregwhitworth> domfarolino: allowing anchors inside of menuitems sounds good
<gregwhitworth> domfarolino: the second part of the issue is part of invoking commands do we need a new element or just use button
<gregwhitworth> domfarolino: I don't think it matters from an accessibilty problem
<gregwhitworth> domfarolino: I want to make sure that we're allowing anchors to be direct children of menulist
<sorvell> q+
<gregwhitworth> domfarolino: your AT will skip over things that are not role=navigation and if we're able to expose normal anchors to ATs it seems like a win
<gregwhitworth> scott4: the proposal was not solving for point 1
<lwarlow> q+
<gregwhitworth> scott4: any of these items would be exposed as a menuitem, it was to bypass the aspect that we can't add href to a menuelement
<gregwhitworth> domfarolino: is there an accessibility win by making navigation anchor tags?
<gregwhitworth> scott4: only if there is work to do a new role that makes them menu items that are also hyperlinks
<gregwhitworth> scott4: the fundamental thing is that menuitems are the only things that are allowed in there
<gregwhitworth> scott4: there has to be more work to make that happen
<gregwhitworth> scott4: that was never a part of the proposal
<gregwhitworth> q?
<gregwhitworth> scott4: the point of this was to make it so the browser handles it so that href on the menuitem
<gregwhitworth> scott4: and it changes their role
<gregwhitworth> scott4: it doesn't make sense to have menuitems sometimes and anchors other times, it then made me think it's weird
<gregwhitworth> scott4: re-use anchor and button and have the button update the roles
<gregwhitworth> domfarolino: it doesn't solve anything for navigation?
<sorvell> q-
<gregwhitworth> scott4: no
<jarhar> q+
<gregwhitworth> scott4: just exploring other current elements that support the majority of this functionality
<gregwhitworth> ack lwarlow
<jarhar> if you want to prevent putting interactives inside of the new menuitem element, we could make it inert by default like we did for the <button> in <select>
<sorvell> q+
<bkardell> right, I was going to queue to say this too
<gregwhitworth> lwarlow: this is the security aspect, sanitizers don't know about menuitem href
<gregwhitworth> lwarlow: the browser can go I'm in a menubar or menulist and map them accordingly
<gregwhitworth> lwarlow: to screenreaders it's the same, but it solves a lot of the duplication of logic
<gregwhitworth> lwarlow: anchors get all the anchor stuff
<gregwhitworth> lwarlow: and likewise buttons you get command and commandfor; rather than having to move that code to somewhere that's shared it makes sense to use a button
<gregwhitworth> lwarlow: if we do add a toolbar it will be a similar authoring experience
<gregwhitworth> lwarlow: as the author I don't need to know that the browser maps those differently internally
<gregwhitworth> lwarlow: if things are doing things in a toolbar that shouldn't it may be confusing
<gregwhitworth> lwarlow: it will be simpler from an authoring perspective
<gregwhitworth> lwarlow: having anchors as a direct child will be valuable regardless and it may depend on interactive behavior
<gregwhitworth> domfarolino: can you tell us the reasoning of the DX improvements
<gregwhitworth> domfarolino: is it due to how toolbars will be authored in the future?
<gregwhitworth> lwarlow: yes
<gregwhitworth> lwarlow: a menubar is a bunch of "show menu" type triggers
<gregwhitworth> q?
<gregwhitworth> ack jarhar
<gregwhitworth> jarhar: I would prefer to not re-use the button element for the menuitem and the button element has a lot of things that we'd have to undo to have them behave this way
<gregwhitworth> jarhar: if I could go back I wouldn't have used button for customizable select
<scott4> q+
<gregwhitworth> jarhar: button supports appearance and do we want the appearance of default buttons for menubars?
<keithamus> q+
<gregwhitworth> jarhar: if we have menuitems that don't support appearance it will be easier
<gregwhitworth> jarhar: have to support a flat tree approach where you can slot a menuitem into another list and that makes it even harder to make it work
<gregwhitworth> jarhar: selectable state for menuoption that won't matter the majority of times
<lwarlow> +1 thinking about it stuff like form attribute on buttons does convince me.
<lwarlow> So perhaps propose we allow <a href> which does menuitem stuff. But not `<button>`
<gregwhitworth> jarhar: if we have anchor than that's ok but I don't want to use button
<gregwhitworth> jarhar: I'd rather add command and commandfor to button than use button in menubar
<gregwhitworth> q?
<gregwhitworth> ack sorvell
<gregwhitworth> sorvell: I echoed jarhar concerns
<gregwhitworth> sorvell: client-side routing they use anchors and they don't actually navigate the page
<lwarlow> Could you explain checkable anchors?
<gregwhitworth> sorvell: if was purely a visual styling thing then it would make sense, but button submits forms - that feels very weird
<gregwhitworth> sorvell: the implementation sounds knarly
<gregwhitworth> sorvell: I know there are issues the other way too but this doesn't sound better
<gregwhitworth> q?
<gregwhitworth> ack scott
<bkardell> s/knarly/gnarly
<gregwhitworth> scott: thanks for the discussion on this
<gregwhitworth> scott: probably makes sense to close this then
<gregwhitworth> domfarolino: I think it's good
<lwarlow> q+
<gregwhitworth> ack keithamus
<gregwhitworth> keithamus: I wanted to offer an alternate or make some rebuttals
<gregwhitworth> keithamus: around appearance: base and I can see pushback when a lot of the functionality is redundant, I don't see why we can't relax it when button inside the menuitem
<gregwhitworth> keithamus: adding a whole new element that borrows from other semantic elements it's a little strange
<gregwhitworth> keithamus: if a menuitem is outside of the menubar how will that behave?
<gregwhitworth> keithamus: if it does a little bit of both, which is what people want from anchors as buttons and buttons as anchors
<gregwhitworth> scott4: there shouldn't be a hyperlink that is also checkable that shouldn't be possible
<gregwhitworth> scott4: thank you keithamus that was some of my rationale and there will be work either way
<gregwhitworth> scott4: I'll defer to you on what has the most work either way
<brecht_dr> q+
<domfarolino> proposed resolution: keep introducing <menuitem> element, instead of using buttons. Table the discussion about anchor children for #1193 where we'll continue to discuss the navigation menubar use case
<gregwhitworth> scott4: what is the usecase for the summary element; they can use that outside of the details element
<gregwhitworth> scott4: I wish HTML broke more often than it does
<gregwhitworth> ack lwarlow
<gregwhitworth> lwarlow: to what domfarolino was saying; I think the argument is that buttons have too much stuff
<gregwhitworth> lwarlow: look at everything that buttons have and what do menuitems have
<gregwhitworth> lwarlow: there are form attribute that you may not want
<keithamus> do we _not_ want forms?
<sorvell> q+
<gregwhitworth> lwarlow: I think anchor should be in menulist maybe not menubar
<gregwhitworth> lwarlow: we could make it so that checkable anchors could be inert and they just don't work
<gregwhitworth> lwarlow: I think we should just have a CSS rule that display: none them if they're outside of the menubar or menulist element
<gregwhitworth> domfarolino: I like the specific children for specific parents
<jarhar> q?
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: for the check state you were saying that a check state on a anchor don't want to occur but if you have an aria-pressed on a button?
<gregwhitworth> scott4: putting bold and underline buttons in toolbars that is something where we would introduce buttons that have a checked state
<gregwhitworth> q?
<gregwhitworth> ack sorvell
<gregwhitworth> sorvell: really briefly, checked anchors in menus do make sense; Chrome has a checked tab in menu and I'd want to do that in the platform
<bkardell> but that isn't a checkbox
<gregwhitworth> domfarolino: that is not an anchor, that is a command that changes something else and it does navigation
<gregwhitworth> domfarolino: but imagine there will be usecase for it
<gregwhitworth> scott4: I want to clarify it though and your usecase makes sense, it's still not a hyperlinking
<gregwhitworth> scott4: it's a command that changes the current view
<gregwhitworth> scott4: I'm referring to a anchor that navigates and is checked; you're not actually navigating
<gregwhitworth> sorvell: I do think people will handle like this
<gregwhitworth> sorvell: I think this is something that people will update the URL and it's an anchor tag
<gregwhitworth> q?
<gregwhitworth> sorvell: but I can re-load that thing
<gregwhitworth> proposed resolution: keep introducing <menuitem> element, instead of using buttons. Table the discussion about anchor children for #1193 where we'll continue to discuss the navigation menubar use case
<sorvell> +1
<masonf> +1
<scott4> +1
<gregwhitworth> RESOLVED: keep introducing <menuitem> element, instead of using buttons. Table the discussion about anchor children for #1193 where we'll continue to discuss the navigation menubar use case
<gregwhitworth> Zakim, end meeting

per today's conversation, i'm going to close this issue. thanks again for considering and discussing.

Navigation Menu

Repository navigation

[menu] - do we need to introduce menuitem elements? #1200

skip all the preamble, here's the proposal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[menu] - do we *need* to introduce menuitem elements? #1200

Description

skip all the preamble, here's the proposal

Activity

lukewarlow commented on Apr 18, 2025

scottaohara commented on Apr 18, 2025

lukewarlow commented on Apr 18, 2025

scottaohara commented on Apr 18, 2025

domfarolino commented on Apr 24, 2025

scottaohara commented on Apr 24, 2025

lukewarlow commented on Apr 24, 2025

josepharhar commented on Apr 24, 2025

css-meeting-bot commented on Apr 24, 2025

scottaohara commented on Apr 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[menu] - do we need to introduce menuitem elements? #1200