[g-a-devel] Using color alone

[Aaron Leventhal <aaronlev moonset net>]

Peter,

The comment about color reminds me -- what about:

Grayed out items (disabled/unavailable)
Visited links

Any good ideas on those? These are common visual representations on both 
Windows & Linux.
Perhaps one can argue that grayed out effect is not a variation of 
color, but brightness/intensity, and is not an issue for users with 
color blindness. I don't know.

- Aaron


Peter Korn wrote:
> Hi Aaron,
>
> > 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 :)
>
> I've found that to generally be the case!
>
>
> OK, so the immediate question here is how do we represent this 
> specific visual information to users with disabilities, and most 
> especially to blind users. There are two levels to ask this question 
> on: the level of "how do we put this into AT-SPI as it is implemented 
> in Firefox right now?", and one level removed of "how should Firefox 
> render this information more generally to users with disabilities?"
>
> For the first question, we could do this directly with 
> AccessibleDescription, which frankly makes the most sense.  To the 
> second question, I would think we would want something like a 
> tooltip-style interface to expose the label, or optionally to have it 
> as a column in the display.  Tooltips by convention are the 
> AccessibleDescription of items when no other AccessibleDescription is 
> set, so that approach ties in nicely with my first suggestion.
>
>
> But in looking at this screenshot, I see an underlying accessibility 
> problem that we also must address.  One key accessibility rule is that 
> you never use solely color to indicate something.  This is codified in 
> Section 508 §1194.21(i):
>
>   Color coding shall not be used as the only means of conveying 
> information,
>   indicating an action, prompting a response, or distinguishing a visual
>   element.
>
> Unless I'm mistaken, label information in this case is shown visually 
> *solely* through color.  As such we have a basic accessibility problem 
> we must also solve.  And the solution to this might well provide us 
> with another solution to the question of how to expose this to users 
> of assistive technologies. E.g. if we introduce a new column titled 
> "label", then the object that is shown in that column (in addition to 
> any color coding) might bear the AccessibleName of "Important", 
> "Work", etc.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > - 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
> >
> >
> >
> > ------------------------------------------------------------------------
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel