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

[Bill Haneman <gnome billhaneman ie>]

Hi Peter, all:

Note that in some toolkits/apps, "greyed out" objects remain in the 
focus chain.  FOCUSABLE means "can ever take focus"; changing that state 
from TRUE to FALSE is not technically incorrect, but it's sort of an 
edge case for the state.

There has been discussion of deprecating either STATE_SENSITIVE or 
STATE_ENABLED (I forget which), but they too are subtly different.  
SENSITIVE/ENABLED are certainly the right ones to look at to determine 
if a GUI control is "greyed out", i.e. potentially actionable but not 
currently "live".

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.  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
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>
>
>