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

[Bill Haneman <gnome billhaneman ie>]

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