GNOME Bugzilla – Bug 53577
KEYNAV: GtkToggleButton, GtkCheckButton, GtkRadioButton
Last modified: 2013-02-04 02:08:34 UTC
A toggle, check or radio button should not be activated if keyboard focus is given to it by using a mnemonic that is shared by another control in the same context. In this case, keyboard focus should be given to that button, at which point: - pressing Spacebar should activate the button; - pressing the same mnemonic again should cycles focus to the next control in the context that shares the same mnemonic; - pressing Enter should activate the window's default button if it has one, otherwise does nothing. When any button within a functional group of mutually exclusive toggle or radio buttons has focus: - pressing Tab should move focus to the control immediately after the last button in that group; - pressing Shift+Tab should move focus to the control immediately before the first button in that group; When any button within a functional group of check buttons has focus: - pressing Tab should move focus to the next button in that group, or to the control immediately after the last button in that group if it is the last button that is currently focused. - pressing Shift+Tab should move focus to the previous button in that group, or to the control immediately before the first button in that group if it is the first button that is currently focused. When any button within a functional group of toggle, check or radio buttons has focus (mutually exclusive or not): - pressing the up or left arrow should move focus to the previous enabled button in the group, wrapping around to the last button in the group if necessary; - pressing the down or right arrow should move focus to the next enabled button in the group, wrapping around to the first button in the group if necessary. [Check http://developer.gnome.org/projects/gap/keyboardnav.html for any later proposals that may not have filtered through to this bug report yet]
A difference between the behavior described here and that on Windows is that on Windows when focus is on a radio button group, the arrow keys change the selected item with the group. So, you focus into the group, the focus is displayed around the currently selected item, and up/down change the selected item. I thought I'd mention this since it doesn't seem to be described in the keybindings document.
This was an oversight on my part... I had meant to mention/propose that behaviour in the document. I'll update it when I get a chance...
The request that Tab or Shift+Tab when on a radio button in a radio button group should move the focus out of the group is difficult. The problem is that up to now when moving focus each child widget in the widget hierarchy is eligible if it is sensitive and drawable and can receive focus. We now want to add another condition: another radio button in a radio button group cannot receive focus via Tab keys if a radio button has focus. I cannot see a clean way of implementing this. An alternative would be to define a GtkRadioButtonGroup widget; the radio buttons in the radio button group would be added to the widget. Moving focus to the GtkRadioButtonGroup would cause the focus to be moved to the first or last radio button. This seems a bit radical for 2.0.
I thought about this some and it turns out that it isn't actually very hard to handle the desired radiobutton behavior. The trick is to only accept the focus on a radio button if it is active (and also if no button is selected in the group to handle that somewhat pathalogical case.) This can be done with an appropriate ->focus() virtual method implementation. The main tricky part of this is handling figuring out what widget in the group to go when arrow keys are pressed. It turns out that the simplest way of handling this is to expose some internals from gtkcontainer.c which already handles arrow-key ordering for focusing. I'm working on a patch to do this now.
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
Was fixed a while ago.
Thought I'd add my keynav comment to this bug rather than log a new one as it's kindof related. I find Arrow keys wrap around Toggle Buttons, Checkboxes, Radio Buttons without an audio beep warning, this would be a really useful feature to include in GNOME2.0. I was using the build from Feb 26th on Solaris, apologies if this feature has been added since.
The problem of focus wrapping around in a group of radio buttons still exists. I have a small patch which fixes this problem. With this patch, when the user tries to naviagte past the first/last radio-button in the group with arrow keys, a system beep sounds. I would like to submit this patch. Someone, please change the status of the bug to NEW.??
Created attachment 7531 [details] [review] Patch has fix for focus wrap around problem in gtkradiobutton
The patch(id=7531) should be applied on the following versions of file(s): gtkradiobutton.c -- 1.41
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
It doesn't make much sense to me to wrap around for radio buttons, and not wrap around for menus. We need to do this in some coordinated fashion.
Forget the comment about menus... I really don't want menus to beep instead of wrapping around. But I still need to think about this a bit more. *** NOTE *** after this issues is resolved, please do not reopen this bug. File other bugs instead. Bugs with dozens of unrelated issues on them don't work.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
FWIW, Windows radio groups seem to wrap around too. Moving this to 2.4.1.
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.
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.
most things here are handled nowadays