[g-a-devel] Re: Using color alone

[Peter Korn <Peter Korn Sun COM>]

Hi Aaron,

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

Link visitation is a color issue; one that I think we've all conveniently not 
dealt with.  With greyed out items, the intensity distinction is I think 
sufficiently large so as to not violate §1194.21(i).


Good point about link visitation...


Peter

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