Re: add libcolorblind as an external dependencie

[Shaun McCance <shaunm gnome org>]

On Fri, 2007-03-23 at 16:14 +0000, Daniel Ruoso wrote:
> Sex, 2007-03-23 �10:14 -0500, Shaun McCance escreveu:
> > Not to be disparaging, but the output on some of those is
> > really pretty grainy, and some of them make the menu text
> > harder to read.  Is there really any form of color blindness
> > for which black needs to be transformed to yellow?
> 
> I've been thinking about this for some time now, and at the end there is
> two thing I think worth doing in libcolorblind...
> 
> 1) The first 6 images were from the SELECTIVE_(SATURATE|
> DESSATURATE)_(RED|GREEN|BLUE). This filter is usefull to differ brown
> from dark green, light purple from baby blue without changing the entire
> color pallete. What I want to is to be able to dinamically change the
> sensitivity level (which would increase or decrease the grain, depending
> on what is on the screen), I mean, how I decide a color must be
> saturated or dessaturated. (and No, black doesn't turn into yellow in
> any filter).
> 
> 2) Implemente the other three remaining filters, but this filters
> require the user to choose a base color. The other filters are
> SELECTIVE_(SATURATE|DESSATURATE), which would allow the user to saturate
> all colors with the same base as the one he chooses (usefull in a
> chart). The other is MONOCHROME_OTHERS which would turn monochromatic
> all colors except the one selected by the user.
> 
> One thing that must be noted is that the colorblind filter is not
> supposed to be used all the time, and fortunally, no gnome application
> actually is colorblind-unfriendly. 

I would disagree that no Gnome applications are unfriendly
to color-blind users.  They're generally not outright hostile,
but not all of them are friendly.  Examples:

* All but one of the themes in Five or More are unusable for
  color-blind users.  The "shapes" theme was added by Callum
  because I really like Five or More, and I couldn't play it,
  and he's nice.  But since it's not the default, screenshots
  in documentation don't use it, so our documentation isn't
  color-blind-friendly.

* The colors of the numbers in Mines are hard-coded.  It's
  still playable, because you can still read the numbers.
  But the colors can help your game if you can distinguish
  them.  (Note that the hard-coded number colors could end
  up being completely unreadable for users with other sorts
  of vision problems, such as people using the high contrast
  inverse theme.)

* The colors for the fill bars in the Disk Usage Analyzer
  are hard-coded.  They used to be PNG images, and the red
  and green were virtually indistinguishable.  Now they're
  custom-drawn, but with hard-coded colors.  While the red
  and green are now distinguishable, the green and yellow
  are not.

That's just off the top of my head.  Not show-stopper bugs,
but they are mild annoyances for color-blind users.

> The problem is mainly with web
> content, when you have charts with colorblind-unfriendly colors. At this
> time, the user is supposed to just turn the filter on on that moment,
> choosing which filter fits best on that image, and after reading the
> image, turn the filter off again.

We certainly have great accessibility inside the desktop,
and I think it's a great idea to make tools to compensate
for the bad accessibility in places we can't control.

What worries me, though, is the discoverability of this
feature.  As a color-blind user, if I encountered some
pie chart on the web with crappy colors, it would never
occur to me to open the screen magnifier.

The technology is cool.  Now we need to shake out the
user interaction.

> Again, this filter is not meant to help usage of gnome applications
> itself, because gnome is already colorblind-friendly. We're talking here
> mainly about web content. To show that, I've taken some usefull
> screenshots using vertical split in gnome-mag [1].
> 
> daniel
> 
> [1] http://people.debian.org/~ruoso/colorblind/

I can see the numbers!

--
Shaun