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

[Aaron Leventhal <aaron moonset net>]

[Resending with screenshot attached]

Screenshot for Thunderbird.

Notice that the Message -> Label submenu shows how to mark these. In
fact you can just hit 0-6 to mark the message.  Each is represented by a
different color.

Doesn't seem like something can be both Work and Important :)

- Aaron






Peter Korn wrote:
> Hi Aaron,
>
> Aaron Leventhal wrote:
> > For the email example, flagged is indicated with a color.
>
> Where is the color?  It is overlaid on the text, or is there a cell in 
> a column that contains a color?  If the latter, then that cell object 
> can convey this information.  Perhaps you can post a screen shot?
>
> > For the IM example, away is indicated with a color. The status string 
> > is not rendered unless you hover over the buddy name.
>
> Ah.  So it is rendered in this case like a tooltip?  We typically map 
> AccessibleDescription to tooltips.
>
> Again, a screen shot would be helpful.
>
> > How would you recommend exposing these today?
>
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > - 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
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel