10000 Don't report menu item/check menu item in browse mode · Issue #1756 · nvaccess/nvda · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Don't report menu item/check menu item in browse mode #1756

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.

Sign up for GitHub

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

Jump to bottom
Open
nvaccessAuto opened this issue Sep 7, 2011 · 15 comments
Open

Don't report menu item/check menu item in browse mode #1756

nvaccessAuto opened this issue Sep 7, 2011 · 15 comments
Labels
ARIA bug feature/browse-mode p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority

Comments

@nvaccessAuto
Copy link

Reported by kevinchao89 on 2011-09-07 02:33
Firefox Nightly 9.0a1 (2011-09-06) and NVDA Main Snapshot 4634

Firefox: http://hanshillen.github.com/jqtest/#goto_menubar
Navigate to menubar, observe each item is identified as menu item, submenu item, clickable; all of this is very verbose, and all that is needed is menubar item;
ENTER on one of the menu items, navigate around, and observe that same level of verboseness exist within each menu item;
When using LEFT/RIGHT ARROWS to go from menu items to mmenu items, NVDA should always speak which menu item is being expanded and which item has focus, which it partially does, but does not always speak menu item that is expanded.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh (in reply to comment description) on 2011-09-15 07:22
Replying to kevinchao89:

Navigate to menubar, observe each item is identified as menu item, submenu item, clickable; all of this is very verbose, and all that is needed is menubar item;

Clickable is no longer spoken as of 47c7a02. However, "sub menu" is required to tell the difference between a menu item that opens a sub-menu and one that doesn't. "Menu item" is spoken so you know what the control is. I guess you could argue these should only be encountered within menu bars or menus, so this doesn't need to be spoken.

ENTER on one of the menu items, navigate around, and observe that same level of verboseness exist within each menu item;

When you pressed enter on the item, it should have switched to focus mode. Menu bars really are intended to be used in focus mode, not browse mode.

When using LEFT/RIGHT ARROWS to go from menu items to mmenu items, NVDA should always speak which menu item is being expanded and which item has focus, which it partially does, but does not always speak menu item that is expanded.

NVDA doesn't speak the new sub-menu when switching between them in desktop applications either. Doing so tends to cause way too much verbosity in various places. In any case, I'd argue this is consistent with current behaviour elsewhere, unless I'm misunderstanding you.

@bhavyashah
Copy link

@jcsteh Assuming that the reported issue still occurs with the latest version of Firefox and elsewhere, your #1756 (comment) seems to be providing cogent justification against this ticket. Could you please clarify if this implies a wontfix, or am I misunderstanding something?

@jcsteh jcsteh added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Aug 14, 2017
@jcsteh
Copy link
Contributor
jcsteh commented Aug 14, 2017

The outstanding issue here is that "menu item" gets reported in browse mode, but it's superfluous, since this should be clear from the reported "menu bar" or "menu". We also don't need to report "check menu item". This would make browse mode consistent with focus mode.

@jcsteh jcsteh changed the title ARIA jQuery Menubar: clickable and menu are spoken each and every time, but menu items are not spoken Don't report menu item/check menu item in browse mode Aug 14, 2017
@jcsteh
Copy link
Contributor
jcsteh commented Aug 14, 2017

P3, because it's annoying but doesn't break functionality and isn't widely reported as problematic by users. Not a candidate for 2017webfix for the latter reason.

@jcsteh jcsteh added the ARIA label Aug 14, 2017
@derekriemer
Copy link
Collaborator

We'd need to report checkMenuItems. How else will we know if it's checked/unchecked?

@jcsteh
Copy link
Contributor
jcsteh commented Aug 14, 2017 via email

@Adriani90
Copy link
Collaborator

@feerrenrut, any updates on this topic? There are several issues on github asking for a possibility to move reporting menu item after the label of the item. Or to suppress reporting menu item for browse mode as long as menubar and out of menu bar is reported. Hearing menu item in a menubar with many items seems to be annoying for many people. See for example different airline websites.

@Adriani90
Copy link
Collaborator

Update with NVDA 2019.3 Beta 2 and Firefox 72.0.1:
In focus mode, the item expanded and the currently focused option is alway reported correctly.
In browse mode, the verbosity is still high, but menu item sub menu is only reported if the menu item has other menu items in it. So this is ok from an user perspective because then I know that I can expand that menu item.
In browse mode expanding the menu item submenu is always reported correctly.
Clickable is only reported when expanding a menu item sub menu and entering the sub emnu. It is also only reported on the last item of the submenu.

@Adriani90
Copy link
Collaborator

In my view, the only point that still remains to be discussed is to suppress the reporting of "menu" on every menu item after entering the menu itself. NVDA already reports "menu bar" when entering and leaving it. So reporting only "item" for every menu item in browse mode would be enough in my view.
But sub menu and clickable should still be reported because this is useful information for an user.

@Adriani90
Copy link
Collaborator

@SaschaCowley could you have a look at my last comment? #1756 (comment)

I guess it should be quite straight forward to change the verbosity of "menu item" just to hear "item" while in a menu bar in browse mode. Or is there anything users would miss after this change?

@SaschaCowley
Copy link
Member

My view is that "item" is not necessary. We don't report this for lists, and menus are essentially just a particular type of interactive list.

@Adriani90
Copy link
Collaborator

@SaschaCowley I agree with you, since NVDA already reports when entering and leaving a menu.
My only expectation in this regard ist that the user should hear when there is a submenu item, similar to focus mode.

@derekriemer
Copy link
Collaborator

What do we want to do if

  1. a menu is unlabeled,
  2. and a menuitem gains focus in browse mode, maybe from pressing a button? or, what do we do when Aria is invalid, so there's a menuitem with no menu parent.

@SaschaCowley
Copy link
Member

@derekriemer as far as I'm concerned, neither of those cases need special consideration.

  1. The menu not being labelled is just as bad as any other container not being labelled, right?
  2. We should still report that you've landed in a menu, I think?
  3. These roles have no meaning when not contained by a menu, so we should just treat them like divs.

@Adriani90
Copy link
Collaborator

I still think reporting "item" and "end of item" when arrowing through menu items in browse mode still stands. The same for menu bar or item sub menu.
Then the first part of the second point raised by @derekriemer is not a problem. When arrowing in browse mode, the user would know when an item begins and when it ends and whether it has a submenu or not.

Additionally, an unassigned key script for menus and another for menu items would be really great. This would reduce verbosity and increase efficiency in many web apps and websites.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ARIA bug feature/browse-mode p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@jcsteh @derekriemer @nvaccessAuto @bhavyashah @SaschaCowley @Adriani90
0