Re: [g-a-devel] Extensible states (or properties)

[Aaron Leventhal <aaron moonset net>]

For the email example, flagged is indicated with a color.
For the IM example, away is indicated with a color. The status string is 
not rendered unless you hover over the buddy name.

How would you recommend exposing these today?

- Aaron

Peter Korn wrote:
> Hi Aaron,
>
> I don't understand why these need to be ATK states.  In the e-mail 
> case you cite, "Junk" and "Flagged for follow up", etc. are either 
> written as text on the screen, or there is an icon that can have an 
> AccessibleName.  This is, after all, how the sighted user gets the 
> information.
>
> In the IM client, your status string example speaks for itself - it is 
> a string.  It should implement Atk_Text of course.
>
> In the calendar, how is this information indicated to the user?  Via 
> icons or text, right?  Again, we have standard ways to convey icon 
> information, and of course text.
>
> While these things are, semantically, "state" things, they are about 
> the state of the application (IM), or of a record in the application 
> (e-mail, calendar), and are already otherwise conveyed using user 
> interface elements that we otherwise would be making accessible.
>
>
> These don't seem like reasons to add new states to me, let alone 
> something that needs to completely change the state mechanism (to 
> allow for arbitrary strings).
>
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> Aaron Leventhal wrote:
> > One thing that has come out in the working group for DHTML 
> > accessibility is the need for extensible states.
> >
> > Some sample use cases:
> >
> > _Email:
> > _An email message may be marked with states such as "Junk", "Flagged 
> > for follow up", "Unread"
> >
> > _IM client:_
> > A buddy in a buddy list can have one of the states: idle, away, do 
> > not disturb, etc. These may not be boolean as there may be a status 
> > string such as "Idle for 33 minutes" or "Away: at lunch"
> >
> > _Calendar:
> > _A schedule item make have a state: conflicting, repeating, 
> > tentative, etc.
> >
> > We can try to expand the states table to contain all of these use 
> > cases, but I don't think we can ever name all of the useful potential 
> > states or properties. At the moment people stuff this information 
> > into a tooltip or accessible name, which isn't a good long term 
> > solution. UI Automation will provide a localized statusString which 
> > will provide this info, but that is not semantic -- it would not 
> > allow the toggling of these states via on onscreen keyboard. On the 
> > other hand, it is a practical, simple solution which gets most of 
> > what's needed.
> >
> > What will ATK provide?
> >
> > - Aaron
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel