GNOME Bugzilla – Bug 512300
(ff3) can not tab across to alternative radio button if one is selected
Last modified: 2008-01-28 21:32:28 UTC
Please describe the problem: in the attached testcase, when the page is loaded, we get the first google link, then red, then green followed by blue, and lastly by the bottom google link. (note that none of the radio btns are selected). when we select one, then tabbing around, we can not focus on the other two alternatives. i.e. google link, (selected colour), second google link. Steps to reproduce: Actual results: Expected results: user should be able to tab across to alternatives. Does this happen every time? yes Other information:
Created attachment 103787 [details] testcase
Jon, I cannot reproduce this. I can Tab to all of them. Mike are you seeing this problem?
Oops, pays to read. The key is that a radio button must be selected. Jon, I can indeed confirm this. It happens whether Orca is running or not. Therefore it's a Firefox bug. I'll file it.
Okay, FF bug filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=414176 I'll block this bug against the FF one. However, if the Mozilla folks choose to fix it (maybe they did it on purpose to make it similar to navigating among radio buttons in dialogs), I strongly suspect Orca will automatically "do the right thing" in providing access to the new object with focus. As a work-around, you can use Orca+Tab to move to the next form field and Orca+Shift+Tab to move to the previous one.
As was just commented upon on our blocking bug: > You can use the arrow keys (either up/down or left/right) to switch > radio buttons within a radio group. This keeps a radio group from > taking up multiple tab stops. Is this inconsistent with other GTK > apps? > > I believe the current behavior was implemented in bug 17602. Now here is where Orca does do a bit of "taking over". When Orca is controlling the caret, Left and Right Arrow move you character by character (i.e. it overrides the default FF behavior). My understanding is that this is what we wanted to be doing, but I'll leave that to our UI guy. <smile> Mike? Beyond that: 1. We have Orca+Tab/Orca+Shift+Tab 2. The comment is accurate: The behavior is consistent with other GTK apps. So.... What shall we do Jon and Mike? 1. Is the Firefox bug really a bug? 2. What if anything should Orca be doing differently?
(In reply to comment #5) > As was just commented upon on our blocking bug: > > > You can use the arrow keys (either up/down or left/right) to switch > > radio buttons within a radio group. This keeps a radio group from > > taking up multiple tab stops. Is this inconsistent with other GTK > > apps? > > > > I believe the current behavior was implemented in bug 17602. > > Now here is where Orca does do a bit of "taking over". When Orca is > controlling the caret, Left and Right Arrow move you character by character > (i.e. it overrides the default FF behavior). My understanding is that this is > what we wanted to be doing, but I'll leave that to our UI guy. <smile> Mike? > Yes you are correct. Left and right arrow are intended to move by character. > Beyond that: > > 1. We have Orca+Tab/Orca+Shift+Tab > 2. The comment is accurate: The behavior is consistent with other > GTK apps. > > So.... What shall we do Jon and Mike? > > 1. Is the Firefox bug really a bug? I don't think so. > 2. What if anything should Orca be doing differently? > Personally I think our behavior is correct. I wouldn't expect to tab between radio buttons.
Just to clarify my previous comment. Up and down arrow should allow the user to move between the radio buttons.
mike: hmm, i dont think it is consistant though. For what other objects do we force the user to use the <orcakey> + arrows? Is there an overall user interaction example/testcase? I found something online a while back, but thought it was outdated at the time. If there is a design document could you please send it my way/point me toward it? Joanie: in the example file above, please select one of the options then use <orcakey> + up/down, can you move between all three options? I dont seem able to. :(
(In reply to comment #8) > mike: > hmm, i dont think it is consistant though. > For what other objects do we force the user to use the <orcakey> + arrows? > Is there an overall user interaction example/testcase? > I found something online a while back, but thought it was outdated at the time. > If there is a design document could you please send it my way/point me toward > it? > Much of this information is contained in the orca.html fire in the doc-set directory however It isn't always completely up to date. Often times more information can be found in specific bug reports. > > Joanie: > in the example file above, please select one of the options > then use <orcakey> + up/down, can you move between all three options? > I dont seem able to. :( > You shouldn't need orca+up/down. It seems to me that simply pressing up/down should move you between the radio buttons in the group.
thank you, i will locate the html file and have a read. to me, all three radio buttons are presented on the same line, and pressing up arrow takes me to the link, and arrowing down from the radio button row takes me to the paragraph. Is it working differently for you?
Now I understand the problem! I didn't realize that they were actually visually on the same line. I'll talk this over with Joanie and then comment more.
As Jon indicated Up and Down Arrow move the user line by line. If the radio buttons are all on the same line, this will not work. Moreover, if the radio buttons are on different lines but not at the very beginning of each line in question, Up and Down Arrow will not move you directly to the radio button. Orca+Up/Orca+Down aren't existing commands as far as I know. <smile> Orca+Left/Orca+Right are commands to move among objects. Orca+Tab/Orca+Shift+Tab are commands to move among form fields. This to me is the most logical approach to take. So back to my original questions which I'll make slightly broader: 1. Left and Right in Orca move character by character. Therefore, they will not move radio button by radio button. Mike indicates this is the desired user interaction. 2. Up and Down in Orca move line by line. Therefore, unless all of the radio buttons are on their own separate lines -- and at the beginning of those lines -- Up and Down Arrow will not move the user to the radio buttons. Mike, is this the desired user interaction? 3. Tabbing among a group of radio buttons when a radio button has focus does not work in Firefox period -- it's not an Orca bug. I've filed a FF bug but I still question if it is a bug or not because the current FF behavior is consistent with other GTK apps. Also, Mike indicated he wouldn't expect Tab to work in this case. Shall I go back to the FF bug and comment that, well, yeah, we agree and never mind? <smile> Or should I leave the request in? FWIW, I'm leaning towards the former. 4. Orca+Tab/Orca+Shift+Tab definitely work. Orca+Left/Orca+Right should provide an additional alternative. That seems to solve the problem without needing the Firefox folks to change their keyboard navigation (which is not unlike moving mountains, especially this close to the release date). 5. What, if anything, do I need to do in order to address this bug? Thanks!! p.s. Jon, we totally need to update the wiki. It's on my list -- but so are a ton of other things. Volunteer wikiers (wiki-ites?) are always welcome. <smile>
Joanie, 1. agreed 2. yes, agreed, infact its just a coincidence that the radio button might be on the next line. but obviously we shouldnt depend on that, it just so happens that it is on a new line. 3. sorry i dont know. if you say it is consistant with other GTK apps then who am i to say. 4. with regard to orca+tab is it only solving radio button issues? (i.e. are we doing the ff3 work that is suppose to be done by tab) or does it do other things too? Infact if it is simply taking us to the next form field, they should have that under "f" in firefox, similar to "h" for headings and "l" for lists, and in that case it would make sense .. f takes us to the next form field. 5. Nothing for the moment Joanie, thanks. re: ps. is that a hint (smiling) yes, but where to start. If you could guide me/give me something to start with, ill try.
(In reply to comment #13) > with regard to orca+tab is it only solving radio button issues? (i.e. are we > doing the ff3 work that is suppose to be done by tab) Orca+Tab is the command to move focus to the next form field regardless of its type. > Infact if it is simply taking us to the next form field, they should have that > under "f" in firefox, similar to "h" for headings and "l" for lists, and in > that case it would make sense .. f takes us to the next form field. Yeah, we started with f in the original implementation of the RFE. Then Mike took it for a spin and realized that f wasn't ideal. Imagine that you've moved to a list. Don't care about it. Press f. So far so good, now you're on a checkbox. Don't care about that. Press f. You're in an entry you don't care about. Press f. You're still in an entry you don't care about and you've just typed an f there. <smile> We went with Orca+Tab because it solves the problem and because Tab is the command to move to the next focusable object, so Orca+Tab is (hopefully) easy enough to remember. > 5. Nothing for the moment Joanie, thanks. Okay, pending Mike's comments, I think I'll close this one out and potentially comment on the FF bug. > re: ps. is that a hint (smiling) I'm a mastery of subtlety, eh? <grin> > If you could guide me/give me something to start with, ill try. If it were me doing it, what I would do is grab the wiki content on FF and compare what's there to three things: 1) The keybindings list in the Orca Preferences dialog for Minefield. The FF specific keybindings should be listed in their own group at the top. What commands are there which are not documented in the wiki? I know for a fact that Orca+Left/Orca+Right aren't there, but I'm not sure if we've added other commands since the wiki was last updated. 2) The app-unique preferences in that same dialog (there's a Minefield page). Are there preferences that are not described on the wiki? 3) The NEWS file in Orca. It's similar to the ChangeLog, but Will breaks it down by version and by app so you can quickly locate FF stuff. When I make a major change in functionality (as opposed to a mere bug fix), I tend to detail that change in the ChangeLog and that gets gets added to the NEWS file. You could probably more or less cut and paste those explanations should you see fit to do so. I might also write an update about the current state of affairs, namely, we're a lot peppier but we have some kinks to still work out in the line nav -- things you can attest to first hand. <smile> Once you've worked out what all needs to be (re)written, you can set up a wiki account if you don't already have one. Then you can edit pages. I can give you info on that when the time comes, should you need it. Send me an email. And thank you, thank you, thank you in advance!!!
(In reply to comment #9) Hey Mike, Its really quite important to have a user interaction document which is up to date an agreed upon and which people can refer back to. interaction design issues shouldnt really live in bug reports, although ofcourse they can be referenced. Having this document makes it easier to oversee consistancy and interaction trends. This would also help programmers, because rigorous tests can be written, and more importantly they can see the end goal for a particular task. If you had the time to update the design document to the current state of affairs it would be of great value. Thank you for your hard work.
I just got off the phone with Mike. Because there are two navigational alternatives (Orca+Tab/Shift+Tab, Orca+Left/Right), we're not going to make any changes to the code at this time. Because the FF behavior is consistent with Gtk (which has been our mantra to them), the FF bug isn't really a bug. Therefore, I'm going to close this one out and comment to that effect on the other.