GNOME Bugzilla – Bug 471955
Orca does not provide access to state changes in HTML radio buttons in FF3
Last modified: 2008-07-22 19:28:31 UTC
Unlike radio buttons everywhere else, merely moving focus to an HTML radio button doesn't cause its state to change. The user has to press space bar on it to select it. When the user does this, we're not doing anything in response to let the user know the current radio button was just selected.
Created attachment 94659 [details] simple test case
Created attachment 94660 [details] [review] proposed patch Sadly, we just can't add radio buttons to the state_change_notifiers because we will wind up speaking the state changes twice *everywhere* but HTML radio buttons. :-( The patch admittedly has some comic value for being a nominee for "Most checks conducted in the performance of a state-change announcement". We do NOT want to speak anything if: * Detail1 == 0 (means the radio button became unselected) * We're not in document content * We're in an ARIA widget (based on the examples I looked at, they seem to work like regular radio buttons) * We clicked on it with the mouse Better ideas welcome; this seems to work. Will?
Created attachment 94661 [details] [review] slight tweak There's no need to pass the event on to default.
> Better ideas welcome; this seems to work. > > Will? Definitely seems to work. And checkboxes work, too (though they always did). I did notice some very strange looking stuff in braille, though. When I tab to the "Yes" radio button, I see the following in the braille monitor: &=y Yes Yes RadioButton Yes & y It seems to be a very happy radio button rivaling Meg Ryan's scene in "When Harry Met Sally". If I put a checkbox in there, it seems to be happy. I'm not thinking terribly wisely at all today, though, but I wonder if we might need some special braille generator for radio buttons just like we have for check boxes?
BTW, this seems like a good enough patch for gnome-2-20, and I say commit it after Mike has tested with it.
> If I put a checkbox in there, it seems to be happy. I mean braille works as I would expect.
Created attachment 94669 [details] [review] a little less Meg Ryan I added a braille generator for radio buttons that parallels what we do with checkboxes.
Mike - please test for GNOME 2.19.92 (this coming Monday).
One small problem here. In gtk applications we show the label before the rolename in braille. In HTML content we are showing the rolename before the label. I think we should stay with what we have in GTK.
The same is true for checkboxes.
From Gecko.updateBraille() # If this is a label that's labelling something else, we'll # get the label via a braille generator. [[[TODO: WDW - this is # all to hack around the way checkboxes and their labels # are handled in document content. For now, we will display # the label so we can track the caret in it on the braille # display. So...we'll comment this section out.]]] # #if self.isLabellingContents(obj, contents): # continue So, Will, what do you think?
Just got off the phone with Will. We're going to open a separate bug on the ordering and the braille and just check in the original one -- technically the second one -- to speak the state changes.
The patch in comment #3 has been committed to both trunk and the gnome-2-20 branch. Moving this to pending.
Opened bug 472377 to deal with the braille issues.
I've tested with trunk and gnome-2-20 and the bug fixed for this bug does indeed look fixed. Marking as verified. Please close as FIXED and thanks for your hard work!