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

["Peter Parente" <parente gmail com>]

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
use to distinguish case #2 and case #3 since Firefox wants to remove
STATE_FOCUSABLE in case #2.

Pete

On 3/2/07, Willie Walker <William Walker sun com> wrote:
> 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
> >>