Aaron Leventhal wrote: > Bill Haneman wrote: > >> My vote would be to retain FOCUSABLE when an object is greyed out, but >> that could confuse clients who expect the object to remain in the focus >> chain. >> >> > First, thanks for your input on this. Not to muck things up, but I would > really prefer that FOCUSABLE is consistent between IAccessible2 and > ATK/AT-SPI. Otherwise every cross-platform app is going to make a > mistake here. In MSAA FOCUSABLE means it's focusable right now, which > means it's cleared if it's not currently in the focus chain. Apps like > Window-Eyes and JAWS use FOCUSABLE to know which objects to visit as the > user moves by focusable item in their review mode. I realize that they > are 2 different APIs, but, do you see my point about trying to keep > things the same as much as possible? > I do see your point. However, there are two downsides; it means the implementation in GTK+ and OpenOffice.org to date is inconsistent with Firefox, and it leaves Peter's problem unsolved.
Bill > - Aaron > >> On the other hand, I don't think there are currently any clients >> which enumerate the FOCUSABLE objects and make such an inference, and >> the upcoming Collection API would allow objects to be returned in "Tab >> order", potentially giving clients a way to obtain the equivalent info >> (i.e. which objects are in the focus chain). >> >> Bill >> >> Peter Parente wrote: >> >> >>> Hi, >>> >>> How should the atk/AT-SPI states be used to indicate a widget is >>> disabled/grayed? In gail, it looks like: >>> >>> 1) STATE_FOCUSABLE && (STATE_ENABLED || STATE_SENSITIVE) means the >>> widget is interactive >>> 2) STATE_FOCUSABLE && !(STATE_ENABLED || STATE_SENSITIVE) means the >>> widget is not interactive because it is currently disabled >>> 3) !STATE_FOCUSABLE means the widget is never interactive so it's >>> neither enabled or disabled >>> >>> In Firefox 3.0, STATE_FOCUSABLE is removed when a widget is >>> disabled/grayed. This makes the second case (currently disabled) and >>> third case (can never be enabled or disabled) indistinguishable. This >>> is problematic for an AT which wants to announce "disabled" when an >>> interactive widget is currently not available for interaction, but say >>> nothing when the widget can never become interactive. For instance, >>> consider a grayed submit button on a web page versus a paragraph of >>> text on the same page. >>> >>> According to the AT-SPI docs: >>> >>> "STATE_FOCUSABLE: Indicates this object can accept keyboard focus, >>> which means all events resulting from typing on the keyboard will >>> normally be passed to it when it has focus." >>> >>> When a control is in a disabled stated, it cannot accept the keyboard >>> focus. Under this interpretation, it sounds like Firefox is doing the >>> right thing. But then there is still a lack of distinction. >>> >>> Does anyone have an elegant solution or recommendation that doesn't >>> involve having the AT revert to guessing which roles are interactive >>> and which are not? >>> >>> Thanks, >>> Pete >>> _______________________________________________ >>> Gnome-accessibility-devel mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>> >>> >>> >>> >>> >> _______________________________________________ >> Gnome-accessibility-devel mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >> >> >> > _______________________________________________ > Gnome-accessibility-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
