GNOME Bugzilla – Bug 364774
Orca should report the quantity of items in a group of radio buttons
Last modified: 2006-12-15 16:05:00 UTC
Orca now reports the number of items in a menu/submenu and a list when you use whereAmI. This functionality would be beneficial in a group of radio buttons as well.
This might be an enhancement that we have to close as "WONTFIX" as I don't believe there is an easy way to determine the radio button group from a accessible radio button object.
Radio buttons should provide a RELATION_MEMBER_OF relation. If I remember correctly (there's some code in default.py around line 1431 that uses this relation), the way this is used is that all radio buttons in the same group list themselves and all other radio buttons in the group in their relations. That is, a radio button has multiple RELATION_MEMBER_OF relations that represent every object in the radio button group. As a result, getting the count should be somewhat trivial. BTW, as a related enhancement - maybe all members of a radio button group should automatically be listed on the braille display? If users agree, we should open a new RFE.
Hmmm. Interesting. Then if this relationship exists, then surely it wouldn't have been too hard to implement bug #348975 - "orca should not speak the role when moving between radio buttons". Should this be reopened and investigated further?
Created attachment 75623 [details] [review] Patch to implement the feature. Here's a patch that sort of does the right thing. As far as I can tell though, the order of each of the members in the radio button group when returned as targets in the realtionship, bears no resemblance to their visual order on the screen. So you can uniquely report "Item x of y" for each one, but it doesn't match up visually to the current position within the radio group. For a blind person, this is probably not a big deal. Patch *NOT* checked into CVS HEAD as "where am I" is currently being reworked.
Hi Rich. I just tried the patch. What I am observing so far is that the item position seems to be consistently/reliably the reverse of the visual order. In other words given a group of radio buttons you get: Visual:Reported Item 1 of 4: Item 4 of 4 Item 2 of 4: Item 3 of 4 Item 3 of 4: Item 2 of 4 Item 4 of 4: Item 1 of 4 Item 1 of 2: Item 2 of 2 Item 2 of 2: Item 1 of 2 etc., etc. So far I've tried this in the Orca preferences dialog, the Ubuntu Network Proxy dialog, the Ubuntu Sound Preferences dialog (System Beep page), and the gedit Print dialog (Job page). If the relationship really is this predictable and is always the opposite of what is visually on the screen, you could just flip 'em. Of course, who knows if you can count on that....
I'm not seeing such consistency with GNOME 2.14 on Solaris though. I tried it with Orca Preferences and gnome-terminal Edit->Current Profile (Effects pane). I'll try it with Ubuntu Edgy (probably tomorrow) and see if its any different there. Hey, maybe somebody has added consistency to at-spi for this in GNOME 2.16...
Good news and bad news. Good news: Add the Evolution Preferences dialog to the collection of examples where the visual position is predictably the reverse of the reported position. Bad news: The patch has a problem in OOo Writer's Options dialog. Steps to reproduce: 1. Launch Orca 2. Launch OOo Writer 2.0.4 3. Tools menu... Options 4. Down arrow to Print 5. Tab twice to move focus to the Printer radio button 6. Press KP_Enter Traceback (most recent call last):
+ Trace 79933
consumed = self._function(script, inputEvent)
text = _("Item %d of %d") % (item, total)
The bad news is yet another Open Office bug. That's saying that there is no entry for the current radio button in the set of radio buttons that it's a member of. Easy to program around, but it's still their bug (or perhaps a poor interpretation of a dubious spec). I'll adjust the patch to fix this (probably tomorrow). Did you try it on Ubuntu with the gnome-terminal Edit->Current Profile (Effects pane)?
I hadn't tried it, but I did just now. Drat! You're right: It looks like you cannot always count on the order being the reverse. :-( None (Item 1 of 3) is reported as 2 of 3. Background image (item 2 of 3) is reported as 3 of 3. Transparent background (item 3 of 3) is reported as 1 of 3. I wonder if there's something dialog box creators can (should) be doing in order for us to reliably get the correct information....
It looks like OOo doesn't have MEMBER_OF as a relation for radio buttons *at all*. I've files a bug against them for it. See issue #71010. http://www.openoffice.org/issues/show_bug.cgi?id=71010
Created attachment 75667 [details] [review] Revised version of the patch to cater for OOo radio buttons.
(In reply to comment #3) > Hmmm. Interesting. Then if this relationship exists, then surely it wouldn't > have been too hard to implement bug #348975 - "orca should not speak the role > when moving between radio buttons". Should this be reopened and investigated > further? The problem is having the speech generator get to the old locus of focus to determine whether or not to speak the role. Is there a facility to allow the speech generator to do this?
For the record, Will and I just discussed this on the phone. A possible solution might be to store the old locus of focus in orca_state.py. For now, we'll leave things as they are though, unless users complain.
On a different note, the new patch works nicely. :-) Thanks Rich!
I notice that this functionality is nicely in the new where-ami-I option. Closing as FIXED.