GNOME Bugzilla – Bug 70372
Keynav and insensitive menu items
Last modified: 2015-12-22 00:01:03 UTC
When there are insensitive items in a menu: a) should they be selectable from the keyboard (and in fact, show mouseover?) [ they aren't currently, and we may not be able to change this in the 2.0.0 timeframe. ] b) If they shouldn't be (or anywyas as currently, aren't) then what should happen in "select first item in the menu item contexts" such as popping up a context menu with Shift-F10: i.) Nothing is selected. Hitting <down> selects the first sensitive item. ii.) the first selectable item is selected i.) has the advantage that if the user hits return immediately, nothing will happen, but the disadvantage that in the popup menu case, _nothing_ is selected/focused, which is visually confusing. (It's not so bad when, say, activating a menu with a mnemonic, since then the focus stays on the menubar.)
Allowing insensitive menu items to be highlighted/navigated is probably the best solution for the user, since: - keynav behaviour remains predictable under all circumstances, - there's no risk of activating the wrong menu item by mistake by not paying attention, - it allows online help/status bar help/tooltips etc. to be accessed for menu items even if they are unavailable-- particularly useful if the help explains how to make the item available again. (Brief aside on popup menus: in a well-designed UI the first item on a popup menu should never really be unavailable anyway-- you could even argue that no items on a popup menu should ever be unavailable, since it's only supposed to show items applicable to the current selection, but in practice it doesn't quite work like that...)
The problem with this is that currently selected and insensitive are exclusive states in GTK+. May be possible to fix this with some hacks (draw the menu item as not insensitive even when it is, and draw the children insensitive.) Not trivial though. (Is a redesigin of the entry popup needed? Cut, the first item, will be insensitive any time no text is selected.)
This could be one of those exceptions :/ I don't recall off-hand, but I think Windows probably has the same problem with its context menus for entry fields. (But of course it has the ability to select 'Cut' anyway, even though it's disabled). The 'next best' alternative would be for Cut and Copy not to appear on the menu at all when no text is selected.... dunno how technically feasible that is, though.
This shouldn't be a problem to implement. In ROX-Filer, we just shade the child widgets, rather than the menu items, and it works fine. We do this mainly so that you can click a menu item to see why it's shaded (since we have to do the messages anyway for the keyboard short-cuts, it seems sensible to make them available via the mouse too). Also means you can set up the short-cuts when you first sit down in front of a new machine without having to work out how to unshade every item in turn ;-) I think it's most important for submenus, though. When a submenu is shaded you should still be able to open it (even though everything inside will also be shaded) so you can see all the functions of the program easily.
One problem with the trivial approach of drawing the menu sensitive (and selected) and the child insensitive is that there is no guarantee in the GTK+ system that the foreground color for insensitive text will be visible against the bcakground color for selected text.
Can't deal with this for the 2.0.0 release.
Hi: this really *has* to be dealt with for 2.0.X release since it proves to be an accessibility stopper. When navigating from menu to menu, "something" must have focus. I think focussing the first selectable item in the menu makes sense here, and in cases where no selectable items are contained in the menu, selecting the menu itself makes the most sense.
I lobby for Owen's suggestion "b-ii" above, with the additional note that if a menu has no sensitive items in it, either: aa) the menu itself should then get focus, or; bb) the menu itself (i.e. the corresponding item on the menubar) should be made insensitive. (bb) above has the disadvantage that a user can't find out what an insensitive menu might have to offer if it became sensitive, thus I slightly prefer (aa) above.
Does #85796 address this, and if so can we close?
I think we might still want to do something better here in the long term; though the 2.2.0 milestone is unlikely. Bumping along to 2.4..
Marking AP3 to reflect a11y team's assessment of a11y impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
i think i'll need something along these lines for the gtk-wimp theme engine too. basically, native win32 draws menuitem backgrounds using COLOR_HIGHLIGHT for any menuitem that is prelit, regardless of whether it is insensitive or not. right now, i believe gtk draws a distinction - insensitive things cannot be prelit as well. therefore gtk menuitem backgrounds get drawn gray instead of blue, and thus look a little out of place. maybe there's a better way to implement what i'm looking for, or maybe i should file another bug for this RFE. any help is greatly appreciated.
There's some discussion about this on the gnome-accessibility and mozilla-accessibility lists at the moment-- Mozilla makes insensitive items navigable, and most of the screenreader users who've participated feel that it would probably be preferable if insensitive items were navigable in GNOME, too. http://mail.gnome.org/archives/gnome-accessibility-list/2004-October/msg00029.html What are the chances that this really will be fixable in gtk 2.6?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
time to close this