Re: [g-a-devel] How to indicate disabled state

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).


Peter Parente wrote:

How should the atk/AT-SPI states be used to indicate a widget is
disabled/grayed? In gail, it looks like:

widget is interactive
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?

Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org

Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]