Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the difference between menu and menubar clearer #1084

Open
JAWS-test opened this issue Oct 6, 2019 · 3 comments · May be fixed by #2056
Open

Make the difference between menu and menubar clearer #1084

JAWS-test opened this issue Oct 6, 2019 · 3 comments · May be fixed by #2056
Assignees
Labels
editorial a change to an example, note, spelling, grammar, or is related to publishing or the repo
Projects
Milestone

Comments

@JAWS-test
Copy link
Contributor

In my opinion, the difference between menu and menubar is not sufficiently explained in the specification because it is only explained in menubar:

A presentation of menu that usually remains visible and is usually presented horizontally.

But the definition of menu does not say that it is not permanently visible. Therefore I suggest to add that to menu:

"A menu is not permanently visible, but is only displayed after user action. It can be, for example, a context menu, a submenu within a menu bar or a menu which is called up via a button."

In addition, I suggest removing the first "usually" in the description of menubar, since it is not clear why this (" usually remains visible") does not always apply.

See w3c/aria-practices#1195

@scottaohara
Copy link
Member

I don't think we should remove "usually" from the intro description to menubar.

Reason being that while a menubar can be permanently visible, it may not always be. For instance, WIndows 10 auto-hides application's menu bars, or other native computer applications, or web apps, can have their menu bar temporarily hidden by the user, as well.

regarding the proposed update to menu, I do like the idea of briefly mentioning example use, e.g. as a context menu, submenu within a menubar, or invoked by button activation. Weaving that into the description of the role would be enough, in my view, to indicate that the menu is not always visible without having to overtly state so.

Interested to know other's thoughts on that.

@JAWS-test
Copy link
Contributor Author

JAWS-test commented Oct 6, 2019

I don't think we should remove "usually" from the intro description to menubar.

I understand and agree.

Nevertheless, I think it would be good to better explain the role menu in contrast to menubar.

For Windows, for example, there is the following, clearly understandable definition

ROLE_SYSTEM_MENUBAR: The object represents the menu bar (positioned beneath the title bar of a window) from which users select menus.
ROLE_SYSTEM_MENUPOPUP: The object represents a menu: a list of options, each with a specific action. All menu types must have role, including the drop-down menus which are displayed when selected from a menu bar; and shortcut menus, which are displayed by clicking the right mouse button.

(According to Core AAM, the ARIA role menu corresponds to ROLE_SYSTEM_MENUPOPUP and the ARIA role menubar corresponds to ROLE_SYSTEM_MENUBAR)

@smhigley
Copy link
Contributor

smhigley commented Oct 7, 2019

Just a quick note -- the Windows API documentation linked in the previous comment is MSAA (the legacy Accessibility API), and not the UIA MenuBar and Menu docs. I'm actually not sure when MSAA docs were last updated, but they generally may not be the best primary reference for ARIA role descriptions.

Even UIA's Menu and MenuBar docs are primarily focused on describing application menus (i.e. the top-level menu that exists outside the focus order and is accessed with Alt). That said, their use isn't confined to application menus, and neither description specifies visibility (neither permanent visibility for menubar nor toggled visibility for menu) as a requirement.

I agree with @scottaohara that mentioning example use cases for each might help make the difference more clear without creating unnecessary limitations on the roles.

@jnurthen jnurthen added this to the ARIA 1.3 milestone Oct 10, 2019
@jnurthen jnurthen added editorial a change to an example, note, spelling, grammar, or is related to publishing or the repo good first issue labels May 5, 2022
@spectranaut spectranaut added this to Chris Lane in ARIA 1.3 Jun 7, 2022
scottaohara added a commit that referenced this issue Oct 6, 2023
@scottaohara scottaohara linked a pull request Oct 6, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial a change to an example, note, spelling, grammar, or is related to publishing or the repo
Projects
ARIA 1.3
Chris Lane
Development

Successfully merging a pull request may close this issue.

6 participants