This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
JDK 6, Ubuntu, dev builds. When I have some form related to issue tracking open, including Find but most especially an issue view/edit page, 1. There are tons of Swing controls with associated mnemonics. This would be fine, except that they collectively override _every single_ mnemonic used for the NetBeans main menu. For example, Alt-F selects the Platform combo rather than the File menu. Since there are no unused mnemonics, I cannot even post an unrelated menu and then use arrow keys to go to the one I want; it is (as far as I can tell) impossible to use the menu without touching the mouse when the bug form is open. 2. Mnemonics are captured even when the form does not have focus! So it is not a workaround to, say, press Ctrl-1 and then Alt-F; the Platform combo still gets selected even though the Projects tab supposedly has focus. Note that for reasons such as these, Firefox no longer binds web mnemonics to Alt-<letter> but rather to Alt-Shift-<letter>. (Try with e.g. Alt-Shift-D for Depends field in this form.) I'm not sure if this is possible in Swing, but if so, it would be much preferable. (Alt-<letter> is customary in dialogs, but from these the main menu would not be accessible anyway.)
Mnemonics work per window on all visible components (I think) no matter where the focus is. True that the clash with main menu mnemonics is not nice. However, at least on Windows you can get a main menu mnemonic invoked by pressing Alt and the letter separately - pressing Alt moves focus to menu bar, then pressing the letter selects the menu. F10 also works, but on Linux it seems it also opens the first menu (File) and then typing a letter works only within this menu. Not sure how feasible is to make Alt-Shift-<letter> work for mnemonics inside a TopComponent. But there is already number of global shortcuts in the IDE with Alt-Shift which would conflict with this. BTW I've looked at the Find Issues form and noticed two mnemonics conflicts just within this for,: * S used both in Issue Type list and Search button, * M used both in Component list and Target Milestone
Also since pressing alt in windows does not always work with jaws enabled, pressing f10 will always put focus on the file menu bar item. You can then use arrow keys to navigate the main menu from there.
*** Bug 212157 has been marked as a duplicate of this bug. ***
would like to have the opinion of UI about this - cc psomol
Created attachment 119255 [details] Main areas of mnemonic/shortcut access inside issue tracking form From UEX point of view no module should override/hide/modify the standard main-menu mnemonics as long as the menu is active and reachable in given context. Any such change seriously degrades user experience, as it imposes the need to think and discover the locally changed UI logic, without actually giving serious enough compensation for that. At least she mnemonics/shortcuts Alt-(F, E, V, N, S, A, R, D, P, M, T, W, H) should thus not be used elsewhere when the respective menus are meant to be accessible. The option proposed in Description of this issue - using Alt-Shift-<letter> instead of Alt-<letter> inside the issue tracking form - could solve this up to a point, but would be difficult to discover by users and would impose the need to learn a new context-dependent shortcut logic. Provided such solution is technically possible in the current window system, I would recommend to at least add tooltips to each relevant component to inform that it is reachable by the Alt-Shift shortcut. If we succeeded to find a solution that would not involve any non-standard shortcut/mnemonic handling, it would be better. I am considering the following. In case of shortcuts we have Guideline 4.5 at http://ucsd.us.oracle.com/projects/developer-tools/people/chris/ToolsStyleguide/KeyboardShortcuts.html recommending to define shortcuts only for often performed actions. Although this can not be applied to mnemonics straight away, in case of a form with large number of visual components it would make sense to follow the same logic. Thus I ask if it is necessary to have mnemonics defined for each component in the form, or whether it would be enough to have mnemonics/shortcuts for a limited number of reasonably chosen components. Assuming users can use Tab key to quickly jump among neighboring components, the mnemonics can then be defined to jump quickly among more distant components or component groups in the form. It seems to me that (not having real usage data) the sufficient quick navigation "anchor" points would be the following: Product (Alt-C) Priority (Alt-Y) Summary (Alt-U) Submit Issue (Alt-I) Add to Action Items (Alt-O) for which mnemonics could be defined as shown here, not interfering with the ones used in main menu (see the list above). Remark: I see such solution preferable to introducing new shortcut logic, but I am aware that this solution is somewhat fragile - it can get difficult to sustain if main menu gets changed or extended, and it can be difficult from internationalization point of view. Therefore I am CC-ing Rich, should he want to comment on that.
> Thus I ask if it is necessary to have mnemonics defined for each component in > the form, or whether it would be enough to have mnemonics/shortcuts for a > limited number of reasonably chosen components. agree. - User editable fields are accessible by tab and the navigation is usually straightforward - from the top of the issue mask down, through all the fields. I wouldn't expect that a user has to jump around very often between e.g. "product" and "depends on", so wouldn't mind to give up all the mnemonics in fields, or to keep only a few of them (though that might seem inconsistent to somebody). - then there are action like submit, refresh, show in browser etc. - accessible by tab and for fast navigation we could have a context menu available in the TC listing all of them
Hey, all. I asked Liza if we've run into this issue in JDeveloper, which can also be very shortcut-heavy on editor forms. We have taken the tactic of not using mnemonics in non-modal forms, because of the very issue that they tend to conflict with keyboard shortcuts for menus and other commonly used functions. I'd suggest we follow the same logic here.
All A11Y bugs needs to be resolved for 7.2
will resolved by 2 fixes: - remove the mnemonics so they do not clash with the menu anymore (the fields are still accessible via tab navigation) - core-main #f39145f224c7 - provide a ctx menu to improve user experience - filed a issue #214117 to track it
Tomas, I'm not sure what you're proposing be placed on a ctx menu. Can you give me more details? Rich
(In reply to comment #10) > Tomas, > I'm not sure what you're proposing be placed on a ctx menu. Can you give me > more details? > > Rich - Submit - Cancel - Refresh - Show in Browser - ...
Ah, got it. Cool, I understand. Thanks!
Integrated into 'main-golden', will be available in build *201206140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f39145f224c7 User: Tomas Stupka <tstupka@netbeans.org> Log: issue #182834 - Overly aggressive capture of mnemonics from issue tracking forms