Re: [g-a-devel] Extensible states (or properties)
- From: Aaron Leventhal <aaronlev moonset net>
- To: Peter Korn <Peter Korn Sun COM>
- Cc: Aaron Leventhal <aaron moonset net>, gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel] Extensible states (or properties)
- Date: Thu, 15 Dec 2005 17:13:43 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]