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

[Peter Korn <Peter Korn Sun COM>]

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