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

[Bill Haneman <Bill Haneman Sun COM>]

Aaron/All:

My thinking is regarding the greyed-out and visited color issues is twofold:

1) the resulting visible indication should be themeable, i.e. link color 
should be specifiable via theme, as should enabled/greyed out, which 
will go a long way to solve color blindness and contrast issues;
2) the 'visited' indication should probably be themeable in a way beyond 
just color, as in the old-fashioned "underline" style for links; i.e. 
"underline visited links" or some such thing.  In other words, the 
themeability of these visual indications probably should extend to 
'style' as well as just color.

regards

Bill

Aaron Leventhal wrote:

> 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
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel