GNOME Bugzilla – Bug 570560
(ARIA) changes to radio buttons using aria-activedescendent property not presented
Last modified: 2011-02-19 16:23:36 UTC
1) Go to http://codetalks.org/source/widgets/radio/radio3.html 2) Tab to any radio button 3) Arrow up/down to select a different radio button. 4) No changes are presented.
The only event I'm seeing on these is an object:state-changed:checked. I'm not seeing any focus: events, or any object:state-changed:focused, or any object:active-descendant-changed events. :-( The radio buttons also seem to lack STATE_FOCUSABLE. I can hack around it if you'd like, but this to me seems like not our bug.
(In reply to comment #1) > The only event I'm seeing on these is an object:state-changed:checked. I'm not > seeing any focus: events, or any object:state-changed:focused, or any > object:active-descendant-changed events. :-( The radio buttons also seem to > lack STATE_FOCUSABLE. > > I can hack around it if you'd like, but this to me seems like not our bug. It certainly sounds like an implementation issue in the ARIA example and/or Gecko. I'm adding David, Marco, and Aaron to the CC list for their opinions, and perhaps maybe a discussion about why such a radio button construct that uses active descendant stuff might be used in the real world.
I agree that this is an implementation issue. That said, my latest check-in associated with bug 571058 causes us to not control the caret in those radio buttons. As for presenting them, that's a small hack I think. I'll go ahead and take this. (Doesn't mean the above issues don't need addressing) :-)
Created attachment 130158 [details] [review] revision 1 Pylinted and regression tested. Will please review. Thanks!
Hi Joanie: Thanks for looking at this. I have a question about this chunk of code: + # ARIA radio buttons which use the aria-activedescendent + # property don't seem to be focusable, or emit any events + # (focus related or active-descendent related) to let us + # know that our location has changed. As a result, this + # change in state (and location) won't be presented. See + # bug 570560. + # + if not event.source.getState().contains(pyatspi.STATE_FOCUSABLE) \ + and self.isAriaWidget(event.source): + orca.setLocusOfFocus(event, event.source) + self.setCaretPosition(event.source, 0) If we can be sure that it's not a Gecko bug to not have a FOCUSABLE state for these aria-activedescendant things, I'm OK with it. If it is a bug and it ends up getting fixed in Gecko, what will the impact be (e.g., will these beast stop working or will they continue to work)? For this chunk, why was COMBO_BOX added? + if obj and (obj.getRole() == pyatspi.ROLE_ENTRY) \ + and obj.parent.getRole() != pyatspi.ROLE_COMBO_BOX: This chunk makes a specific comment about aria-activedescendant radio buttons, but ends up checking for all radio buttons. Is that OK? + # ARIA radio buttons which use the aria-activedescendent + # property don't seem to be focusable, or emit any events + # (focus related or active-descendent related) to let us + # know that our location has changed. See bug 570560. + # + elif obj.getRole() == pyatspi.ROLE_RADIO_BUTTON: + return False Thanks!
http://codetalks.org/source/widgets/radio/radio3.html looks busted to me, firebug tells me that aria-activedescendant isn't updated which kind of make the test... uhm... not ideal. :( BTW "setLocusOfFocus" -- love it! Must review more orca code sometime.
(In reply to comment #6) > BTW "setLocusOfFocus" -- love it! Must review more orca code sometime. Yeah - the name was based upon some Raskin and Cooper articles I had read regarding locus of attention. I probably should have stuck with locusOfAttention, but locusOfFocus sounded too cool. Will
Hi Will. Thanks for the review! > Thanks for looking at this. I have a question about this chunk of code: > > + # ARIA radio buttons which use the aria-activedescendent > + # property don't seem to be focusable, or emit any events > + # (focus related or active-descendent related) to let us > + # know that our location has changed. As a result, this > + # change in state (and location) won't be presented. See > + # bug 570560. > + # > + if not event.source.getState().contains(pyatspi.STATE_FOCUSABLE) \ > + and self.isAriaWidget(event.source): > + orca.setLocusOfFocus(event, event.source) > + self.setCaretPosition(event.source, 0) > > If we can be sure that it's not a Gecko bug to not have a FOCUSABLE state for > these aria-activedescendant things, I'm OK with it. I'm not sure we can be sure about this. (I think it's a bug.) Regardless.... > If it is a bug and it ends > up getting fixed in Gecko, what will the impact be (e.g., will these beast stop > working or will they continue to work)? If these widgets gain STATE_FOCUSABLE via bug fix, I would hope that they would also gain STATE_FOCUSED along with emitting the appropriate focus: and object:state-changed:focused events. In which case, my assumption is that our normal focus tracking behavior would do it's thing and these beasts would JustWork(tm) -- just like the other ARIA radio buttons we currently provide access to. That said, I now have a feeling that I'm missing something. :-) Therefore, what are you thinking/suggesting? > For this chunk, why was COMBO_BOX added? > > + if obj and (obj.getRole() == pyatspi.ROLE_ENTRY) \ > + and obj.parent.getRole() != pyatspi.ROLE_COMBO_BOX: Because of this bit: @@ -2782,15 +2797,13 @@ if not self.inDocumentContent(): return False - if not self.isNavigableAria(orca_state.locusOfFocus): - return False - if keyboardEvent.event_string in ["Page_Up", "Page_Down"]: return False Radio buttons (and check boxes) should not be considered "navigable ARIA" as a general rule. However we do want to allow the user to arrow left and right within the text associated with the control. Therefore I moved the isNavigableAria check down a tad: @@ -2830,6 +2843,18 @@ and not self._autocompleteVisible: weHandleIt = keyboardEvent.event_string in ["Up", "Down"] + elif obj and self.isAriaWidget(obj) \ + and obj.getRole() in [pyatspi.ROLE_RADIO_BUTTON, + pyatspi.ROLE_CHECK_BOX]: + text = self.queryNonEmptyText(obj) + if not text: + weHandleIt = False + else: + weHandleIt = keyboardEvent.event_string in ["Left", "Right"] + + elif not self.isNavigableAria(obj): + weHandleIt = False Doing this means that we examine objects of ROLE_ENTRY independent of whether or not the are ARIA widgets -- which I think gives the end user a more consistent experience interacting with entries. But we do have ARIA combo boxes which are implemented as entries whose parent is a combo box. For those beasts we don't want our entry handling to kick in. (Currently that never happens because we check for that condition in isNavigableAria.) Admittedly, this is a change in need of a comment. Sorry! Alternatively, I could move the radio button/check box handling above that for entries. Thoughts? > This chunk makes a specific comment about aria-activedescendant radio buttons, > but ends up checking for all radio buttons. Is that OK? > > + # ARIA radio buttons which use the aria-activedescendent > + # property don't seem to be focusable, or emit any events > + # (focus related or active-descendent related) to let us > + # know that our location has changed. See bug 570560. > + # > + elif obj.getRole() == pyatspi.ROLE_RADIO_BUTTON: > + return False I believe it is. All other radio buttons have STATE_FOCUSABLE -- as expected. As a result, isNavigableAria returns False. But that's not clear from my comment. I'll write a more detailed one to clarify that.
(In reply to comment #6) > http://codetalks.org/source/widgets/radio/radio3.html looks busted to me, > firebug tells me that aria-activedescendant isn't updated which kind of make > the test... uhm... not ideal. :( Agreed on the "not ideal. :(". Plus the lack of STATE_FOCUSABLE and STATE_FOCUSED. Plus the lack of focus: and object:state-changed:focused events. Plus the parent panel seems to lack STATE_MANAGES_DESCENDANTS and fails to emit object:active-descendant-changed events. Basically, this widget doesn't behave like Gtk+ widgets at all. My patch was an attempt to hack around all of the above in time for the GNOME 2.26 release. I for one would rather see it fixed on the ARIA/Gecko side of things. :-) > BTW "setLocusOfFocus" -- love it! Must review more orca code sometime. We're nothing if not poetic. :-) Anyhoo, what do we want to do about this test case and implementation? Proceed with a hack or cause it to be fixed so that it is implemented in a fashion more consistent with other widgets like it?
I feel the real bug is in the codetalks example.
(In reply to comment #10) > I feel the real bug is in the codetalks example. That's my general impression, too. I really don't like the idea of make a whole bunch of hacks to make a broken test page work. Having said that... Joanie -- your patch addresses more than the bug opener, right? That is, my understanding is that it's related to comment #3 and fixes more than just the broken radio buttons on the broken test page. Can you describe this in more detail so I don't go on my "high impact low risk" rant again? ;-)
I'll pull that out as a separate bug. :-)
We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place. Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.
The lunch options and drink options selectors seem to work. We don't seem to get focus events, but do get object:property-changed:accessible-parent and object:property-changed:name-changed for items that seem to have names that seem to be related to the right selector. So, since we seem to have a broken test working reasonably well I'm closing this, if someone would still like to see more work here please reopen.