You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've already provided a significant number of edits/suggestions to the doc, but there are still open questions and use cases in the proposal that I think could benefit from others weighing in.
Per the title of this issue - one such topic is around creating navigation menus. I've mentioned in previous open UI discussions and in the original google doc for the proposal that using menus for navigations is a rather contentious topic - but maybe this is an opportunity to help settle that. The original proposal simply suggested adding a type=navigation or similar to the menubar element. But my comment on that was something like
well what does that (type) even mean or do? As of now a menu used for navigation vs used as a more traditional menu have no actual difference to each other - so providing a "type" is meaningless unless there's an actual plan for how that would modify the user experience.
For instance, is there opportunity for new mappings that could better surface a menu or individual menuitems as behaving like links? Are there ideas on potential UA styling to help differentiate or communicate the changed keyboard behavior for keyboard users?
Even without consensus on full support for a "navigation menu" - the reality is that people will have valid use cases for wanting to have menuitems link off to other web pages. If that is supported natively (e.g., by allowing the href attribute to be specified on menuitems so as to reduce the need for JS) then it stands to reason that people will extend that individual use case into a full blown navigation menu.
I don't see fighting this as a reasonable path forward. I know that there are some members of the group that might actually want this, where there are some that don't. How can we meet in the middle to help make this a use case people could be happy (enough?) with?
The text was updated successfully, but these errors were encountered:
scottaohara
changed the title
Concerning navigation "menus"
Concerning navigation "menus" (open ui related)
Apr 16, 2025
@keithamus I assigned you because of your interested to read the background context -- but I'm not sure there is an action item other then keep an eye on the proposal and feel free to bring this topic back to the group as the proposal continues to evolve.
A possible way of using these new openUI elements for navigation use case could IMO be the following:
Each of the three elements (menubar, menulist, and menuitem gets in this use case the attribute type=nav
The corresponding menuitem as well as all menuitem children of menubar and menulist with this type set are mapped to the link role with the href value used in the menuitem
This approach would make all links in the accessibility tree for direct use and for the composition of link lists by screen readers. Also the dictating software would use the menu item text as links for direct activation.
The only real new UI thing in the new-style navigation menus were the keyboard navigation: Only one tab stop and arrow key navigation through the menu. I find this a positiv development.
There is an open ui proposal for introducing (re-introducing) menubar, menu(list) and menuitem elements.
I've already provided a significant number of edits/suggestions to the doc, but there are still open questions and use cases in the proposal that I think could benefit from others weighing in.
Per the title of this issue - one such topic is around creating navigation menus. I've mentioned in previous open UI discussions and in the original google doc for the proposal that using menus for navigations is a rather contentious topic - but maybe this is an opportunity to help settle that. The original proposal simply suggested adding a
type=navigation
or similar to themenubar
element. But my comment on that was something likeFor instance, is there opportunity for new mappings that could better surface a menu or individual menuitems as behaving like links? Are there ideas on potential UA styling to help differentiate or communicate the changed keyboard behavior for keyboard users?
Even without consensus on full support for a "navigation menu" - the reality is that people will have valid use cases for wanting to have menuitems link off to other web pages. If that is supported natively (e.g., by allowing the href attribute to be specified on menuitems so as to reduce the need for JS) then it stands to reason that people will extend that individual use case into a full blown navigation menu.
I don't see fighting this as a reasonable path forward. I know that there are some members of the group that might actually want this, where there are some that don't. How can we meet in the middle to help make this a use case people could be happy (enough?) with?
The text was updated successfully, but these errors were encountered: