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?
- 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
