GNOME Bugzilla – Bug 138085
cannot keynav to selectable labels
Last modified: 2011-02-04 16:16:16 UTC
Example: nautilus, file properties, 'Basic' page tab The fields 'Type' 'Contents' etc cannot be reached with keynav. This is key for accessibility/gnopernicus for speech feedback.
Have you tried control-tab?
Ctrl+Tab does not work as it is used to move focus out of the GtkNotebook.
Padraig, Regarding a11y and screen reading the information of these labels, should 1. this bug be marked a higher priority or 2. is it up to gnopernicus to use a different approach to reading this information and open a new bug? Either way, there must be an open a11y bug on this subject with a high priority.
Calum, Can you suggest what should be done about the clashing of keybindings: Ctrl+Tab is used to move focus out of a GtkNotebook and it is also used to keynav to selectable labels.
The only alternative idea we could come up with would be a mode, which could be toggled with a keybinding, to determine whether labels should be included or not. Would that be acceptable ?
Hmmm... so, I guess this is an unforeseen consequence of the discussion in bug 59707 (which from Owen's final comment sounded like it wasn't necessarily supposed to be the final solution, so I'm not sure if it should really have been marked "fixed"). I'd really like to see us avoid a mode for this sort of thing... how would a user find out about it? How would they tell whether it was on or off at any given time? Within a single application you have the option of a menu item that shows you a mode's current state and the keyboard shortcut for toggling it. But I don't think we could really put such a thing on the desktop Actions menu :) (We could, perhaps make a case for putting it in the keyboard accessibility applet, but of course that only helps users who are running GNOME). I'm afraid the only other solution I can think of at the moment, though, is to temporarily stop Ctrl-Tab from breaking out of a notebook, while we fix everything that needs to be fixed to have it work the way we originally wanted to (i.e. so that focusable labels appeared in the regular Tab sequence, but without giving focus to something stupid when the dialog first opens).
Created attachment 27803 [details] [review] Patch to implement Calum's suggestion
We would also have to remove Ctrl-Tab bindings from scrolledwindow, if we go this route... Calum, do you have a proposal for a different escape-from-container keybinding ? Or are you fine with just dropping that functionality ? What does Java use for this ?
I don't see how we can afford to lose the escape-from-container functionality, and substituting another keybinding instead seems equally wrong.
I can't find a suitable Java app to test right now, but FWIW I don't think it (or any other toolkit that springs to mind) implements Ctrl-Tab for tabbed panes or scrolled windows. I can't really think of any other shortcut that would make sense, though (and certainly not one that would make sense for just these two cases). If we don't want to drop the shortcut from these two controls, the only other thing I can suggest is to go back to the original suggestion: put selectable labels back in the regular tab sequence, patch GtkMessageDialog to make sure it always focuses the default button first rather than the message (which IIRC was the main reason the original patch was backed out), and file and fix any other issues in individual dialogs as they come up. I can't imagine there would really be too many, as regular dialogs should rarely need to use selectable labels.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
I have put selectable labels back in the regular tab chain now, and modified GtkDialog to skip labels when looking for the right widget to focus initially. This seems to work ok with message dialogs, and also with GnomeAbout.