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

[Bill Haneman <Bill Haneman Sun COM>]

Aaron Leventhal wrote:

> 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?
I would expose them via AtkText TextAttributes, and in this specific 
case it may make sense to (redundantly) mark them via AtkObject's 
atk_object_set_attribute and then expose them via 
atk_object_get_attributes().  The same thing could be used to mark the 
messages as "label:Work", "priority:Normal", etc. etc.   If you wanted 
to do it with the previous/stable ATK API (before we added per-object 
attributes), you would use semantic text attributes for the "label", 
i.e. mark the text range exposed by the AtkText object as "Work".
(Of course if some other onscreen indication were to pop up, such as a 
tooltip etc, then of course that onscreen object would need to be 
exposed as well, via the normal mechanisms for onscreen components.)
Bill

> - 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