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

[Willie Walker <William Walker Sun COM>]

I would prefer to remain with what gail does; I view it as the reference 
implementation of the AT-SPI.  Changing the behavior of an established 
meaning and implementation to accommodate a difference in a new API for 
a different platform (IAccessible2) seems odd to me.  It also seems like 
something that would put existing assistive technologies that depend 
upon the current implementation at risk.

Having said all that, we currently use STATE_SENSITIVE in Orca to 
determine if anything (e.g., a label, a pushbutton, etc.) is grayed out 
or not.  This may or may not be the right thing to do, but empirical 
testing in an ambiguous world seemed to indicate this was the most 
reliable check.

Of course, if there were one common accessibility infrastructure for all 
platforms and we were all working against that infrastructure, the story 
would be different.  IMO, that's the next generation we should be 
striving for rather than repeatedly reinventing the same API model for 
specific platforms.  Based upon my experiences and discussions with 
folks over the past few years, not many people are ready for that yet.

Will

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