headers
Peter Parente | 1 Mar 2007 17:54
Picon
Gravatar

How to indicate disabled state

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.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bill Haneman | 1 Mar 2007 18:26
Picon

Re: How to indicate disabled state

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
(Continue reading)

Permalink | Reply | 9 comments |
headers
Aaron Leventhal | 2 Mar 2007 04:21

Re: How to indicate disabled state

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:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bill Haneman | 2 Mar 2007 11:40
Picon

Re: How to indicate disabled state

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).
(Continue reading)

Permalink | Reply | 7 comments |
headers
Willie Walker | 2 Mar 2007 15:08
Picon

Re: How to indicate disabled state

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Peter Parente | 2 Mar 2007 15:12
Picon
Gravatar

Re: How to indicate disabled state

Hi Will,

So how does Orca distinguish the case of some interactive widget being
disabled from some widget that can never be enabled? Does Orca say
disabled in both cases? Or, when you notice state sensitive is
missing, do you check again other information (e.g. list of roles that
could be enabled/sensitive, existence of certain interfaces)?

It is this distinction that I'm most concerned about.

Pete

On 3/2/07, Willie Walker <William.Walker <at> sun.com> wrote:
> 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Willie Walker | 2 Mar 2007 15:27
Picon

Re: How to indicate disabled state

Hi Peter:

> So how does Orca distinguish the case of some interactive widget being
> disabled from some widget that can never be enabled? Does Orca say
> disabled in both cases? 

Can you enumerate some actual use cases?  Concrete examples might make 
this discussion easier.

Thanks!

Will

>> 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
>>
Permalink | Reply | 4 comments |
headers
Peter Parente | 2 Mar 2007 16:17
Picon
Gravatar

Re: How to indicate disabled state

Sure. Here are examples representative of the three cases we want to
handle in LSR.

1) The user tabs to the Close button in the gedit settings dialog. In
this case, we might say the name of the button, the role of the
button, and the mnemonic for the button.

2) The user reviews to a grayed out menu item in gedit. In this case,
we might say the name of the menu item, the role of the menu item, and
the word "disabled" to indicate that the menu item is not currently
active. We want to say "disabled" here to inform the user that this
menu item could potentially become enabled for regular interaction by
changing the state of the program (e.g. inserting some new text in a
document enables the Save menu item).

3) The user reviews to the toolbar in the gedit main window. In this
case, we might say the text on the toolbar and its role. However, we
do not want to say "disabled" because this the toolbar is never
technically enabled for interaction. That is, we do not want the user
thinking it could be enabled for interaction by changing the state of
the program (e.g. nothing I do in the program will ever enable/disable
the toolbar such that I can interact with it).

The way gail distinguishes these three cases is the following:

1) STATE_FOCUSABLE and (STATE_ENABLED or STATE_SENSITIVE)
2) STATE_FOCUSABLE and not (STATE_ENABLED or STATE_SENSITIVE)
3) not STATE_FOCUSABLE

The original question I was asking was what other techniques can we
(Continue reading)

Permalink | Reply | 3 comments |
headers
Willie Walker | 2 Mar 2007 17:44
Picon

Re: How to indicate disabled state

Thanks!  These help.  Let's focus on the SENSITIVE state as a means to 
do what you want.  I verified all these examples using at-poke.

> 1) The user tabs to the Close button in the gedit settings dialog. In
> this case, we might say the name of the button, the role of the
> button, and the mnemonic for the button.
>   

In this case, it is not grayed and it is SENSITIVE.

> 2) The user reviews to a grayed out menu item in gedit. In this case,
> we might say the name of the menu item, the role of the menu item, and
> the word "disabled" to indicate that the menu item is not currently
> active. We want to say "disabled" here to inform the user that this
> menu item could potentially become enabled for regular interaction by
> changing the state of the program (e.g. inserting some new text in a
> document enables the Save menu item).
>   

Let's take the "Revert" menu item, which is grayed until you make 
changes to a file that you've saved or read in.  The "Revert" menu item 
doesn't have the SENSITIVE state until you make a change to the contents 
on the screen.  As soon as you make a change, it gets the SENSITIVE 
state and is ungrayed.

> 3) The user reviews to the toolbar in the gedit main window. In this
> case, we might say the text on the toolbar and its role. However, we
> do not want to say "disabled" because this the toolbar is never
> technically enabled for interaction. That is, we do not want the user
> thinking it could be enabled for interaction by changing the state of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Parente | 2 Mar 2007 18:13
Picon
Gravatar

Re: How to indicate disabled state

> In this case, the toolbar has the SENSITIVE state and is not grayed.

Good. Now, look at a Firefox paragraph or other element inside a
webpage that is not interactive and compare it with an element that is
interactive but currently grayed.

Pete

On 3/2/07, Willie Walker <William.Walker <at> sun.com> wrote:
> Thanks!  These help.  Let's focus on the SENSITIVE state as a means to
> do what you want.  I verified all these examples using at-poke.
>
> > 1) The user tabs to the Close button in the gedit settings dialog. In
> > this case, we might say the name of the button, the role of the
> > button, and the mnemonic for the button.
> >
>
> In this case, it is not grayed and it is SENSITIVE.
>
> > 2) The user reviews to a grayed out menu item in gedit. In this case,
> > we might say the name of the menu item, the role of the menu item, and
> > the word "disabled" to indicate that the menu item is not currently
> > active. We want to say "disabled" here to inform the user that this
> > menu item could potentially become enabled for regular interaction by
> > changing the state of the program (e.g. inserting some new text in a
> > document enables the Save menu item).
> >
>
> Let's take the "Revert" menu item, which is grayed until you make
> changes to a file that you've saved or read in.  The "Revert" menu item
(Continue reading)

Permalink | Reply | 1 comment |

Gmane