Re: [g-a-devel] Trying to understand STATE_SENSITIVE

[David Bolter <david bolter utoronto ca>]

I guess an underlying question is: do we need to expose all gui states 
though a11y api?  It is tempting to say yes so that we don't limit 
possibilities, but if there is a practical cost (e.g. IAccessible2 
implementations, maintenance thereof) it seems murkier. We know one 
common approach to API design is to provide only what is needed today 
and let consumers of the API request additional API later.  That said, I 
suppose it could still be argued that AT is more likely to use API if it 
is in his/her face, but that doesn't seem to happen as often as we might 
think. My rambling alarm is going off so I'll stop here.

Bill would a use case of a button that is sensitive but not enabled be 
for example a button that appears greyed out but still reacts to user 
action on it in some way, say with a buzzer sound?  If it did anything 
more useful... the GUI designer should probably be shot^D^D^D^D confronted.

cheers,
David

Bill Haneman wrote:
> Aaron Leventhal wrote:
>   
> > STATE_SENSITIVE doesn't make sense to me. It think it should either be 
> > deprecated or the ATK/AT-SPI docs need to be clear. Is STATE_SENSITIVE 
> > doing something we can't do with other states such as ENABLED and 
> > INDETERMINATE?
> >     
> Yes.  I attempted to explain this in the API docs for AT-SPI.
>   
> >  It seems like everything in Mozilla that's enabled should 
> > also be sensitive? Not filing a bug because I'm not sure what to 
> > recommend in the bug.
> >
> > ATK:
> > ATK_STATE_SENSITIVE   Indicates this object is sensitive
> > -> Self-referential sentence
> > ATK_STATE_ENABLED   Indicates that this object is enabled. An 
> > inconsistent GtkToggleButton is an example of an object which is 
> > sensitive but not enabled.
> > -> What's an inconsistent button? Why isn't it ENABLED and INDETERMINATE?
> >
> > AT-SPI:
> > STATE_SENSITIVE   Indicates this object is sensitive, e.g. to user 
> > interaction. STATE_SENSITIVE usually accompanies STATE_ENABLED for 
> > user-actionable controls, but may be found in the absence of 
> > STATE_ENABLED if the current visible state of the control is 
> > "disconnected" from the application state. In such cases, direct user 
> > interaction can often result in the object gaining STATE_SENSITIVE, for 
> > instance if a user makes an explicit selection using an object whose 
> > current state is ambiguous or undefined.
> > -> I don't understand this
> >   
> >     
> 'ENABLED' is usually not appropriate for GUI items that don't currently 
> reflect the application state (i.e. are not 'wired in' to the app 
> state), but such buttons can nonetheless react to user interaction (in 
> which case they are still SENSITIVE).
>
> For instance, if a 'greyed out' button changes to 'not greyed out' when 
> you click on it or otherwise interact with it (which can happen in some 
> edge cases), it is SENSITIVE because it reacts to user interaction, but 
> it still started out 'grey' to indicate that it was not in sync with the 
> application state prior to user action.
>
> You are right that this is similar to what can happen with INDETERMINATE 
> state, but not quite the same.
>   
> > STATE_ENABLED   Indicates that this object is enabled, i.e. that it 
> > currently reflects some application state. Objects that are "greyed out" 
> > may lack this state, and may lack the STATE_SENSITIVE if direct user 
> > interaction cannot cause them to acquire STATE_ENABLED.
> > -> I don't understand this
> >
> > Also gok/gok-keyboard.c:
> > (gok_style_if_enabled): Check for SPI_STATE_SENSITIVE
> > instead of SPI_STATE_ENABLED; this is because SENSITIVE
> > has the semantics we really want, ENABLED can be false for
> > a few actionable elements such as radiobuttons which are in
> > the "indeterminate" state (i.e. no radiobutton in the group is
> > toggled yet). Fix for bug #136877.
> >
> > -> I don't see why radio buttons aren't considered enabled in this state.
> > -> Is INDETERMINATE expected on radio groups with no no checked radio 
> > button?
> >   
> >     
> Not sure about this last question.  I think "no" since states like this 
> aren't usually applied to groups, only to individual actionable 
> components (and the individual radio buttons are probably not, in this 
> case, indeterminate).
>
> Agreed that this is a confusing area, but the semantics of GUI 
> components are like that (in fact GUI component semantics are where most 
> of these states are borrowed from - for instance read the Java JFC docs 
> regarding components - GTK+ is similar too).
>
> Bill
>   
> > - Aaron
> > _______________________________________________
> > 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
>