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

[Aaron Leventhal <aaronlev moonset net>]

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