Re: Accessibilty module for colorblind people

[Bill Haneman <Bill Haneman Sun COM>]

Hi Daniel:

Colorblindness is certainly one of the more common issues that impact 
the usability of our visual interfaces.  It's great to have you onboard 
to help make our desktops more usable.

Enhancements that support colorblindness usually work in one of two 
ways; firstly, themes are provided to select a color and contrast 
environment that suits a particular user's color perception.  The second 
way that colorblindness can be addresses is via "filtering" the entire 
desktop - this is usually done in "magnifier" software, at least in the 
Windows world.  The screen might be "magnified" at 1:1 ratio (i.e. no 
actual enlargement) but re-colored when presented onscreen.

On the Gnome (and KDE) desktops we have a problem with using themes for 
this - we need more colors in our themes, so that applications don't 
"hard code" colors for things like pie charts and other graphics.  
(Hard-coding colors is already something that is considered an 
accessibility violation, but we need more colors in our themes in order 
to give applications a reasonable alternative).  Once we do this, I 
think we would actually have better visual results that what we can 
easily achieve by re-coloring or transforming the color space of our 
user interface - for instance, color transformation which might work 
well to make a pie chart more readable could make a photo really awful 
and distorted.  So in that respect I think enhancements in the theme 
space would be very beneficial and might be the top priority.

Re-coloring the entire screen makes sense in some situations (but can 
produce ugly or unpleasant results sometimes).  As Carlos has said, we 
have a magnification service built into Gnome already (KDE also has a 
magnification utility), and I tend to think this is the best place to 
put recoloring utilities for this second approach to color 
customization.  The COMPOSITE extension looks to me like the best way to 
achieve this - which is another reason for doing it in the magnifier, 
since otherwise our colorblindness support would conflict with 
magnification. 

The idea of making recoloring and magnification both be modular 
compositing manager plug-ins makes a lot of sense; however I think it 
may take some time to come up with an API for it that actually works for 
all the kinds of transformations and rendering changes we will want to 
do.      We also would want to avoid conflicts between, for instance, a 
theme for deutanopia and a compositing filter for the same.
If the recoloring code was written as a "plug in" for gnome-mag, without 
explicit Gnome dependencies, then other projects like KDE could use it 
too, and it could also be applied to images instead of the whole screen, 
which seems like a good thing to me.

Best regards,

Bill

Daniel Ruoso wrote:
> Hi,
>
> I am colorblind. This problem doesn't cause much trouble, so it's not
> something that really makes the computer useless without an
> accessibility software. It would be better if everyone could take that
> into consideration before drawing a chart, but unfortunally that isn't
> always true. Sometimes a chart uses brown-green, purple-blue
> combinations which are just useless for my type of colorblindness.
>
> Here is my plan so far:
>
> 1) Create a library with a set of predefined color filters usefull for
> colorblinds, for instance:
>  * selective red saturation:
>    This would take colors where red is one of the dominants (except 
>    gray) and would saturate it to the maximum. So people with problem in
>    the red cones can differentiate brown from red and purple from blue.
>    Example: #555500 becomes #FF5500.
>  * selective red dessaturation:
>    This is the inverse of the above.
>    Example: #555500 becomes #005500.
>  * Hue shift
>    This would displace the hue, preserving saturation and value.
>    Example: #555500 becomes #005555.
>  * monocrome
>    This would take a base color and turn all the others to greyscale.
>
> 2) Integrate it with the desktop in a way that I press a keystroke and
> activate my default filter with the default settings. Or use a window
> button (at the side of minimize, for instance) to get to a filters menu
> where I can activate any other filter at any time in any window.
>
> This way, when seeing a chart with dubious colors I could just press the
> keystroke to read the chart and then press the keystroke again to
> continue using the software (or continue to using it with the filter
> active).
>
> 3) Have a accessibility configuration which would perform the ishihara
> test for those who doesn't know which time of colorblindness they have
> indicating what filter would be the most usefull in most cases (for
> example, the selective red saturation for mine colorblindness but
> probably selective green saturation for other type and so on).
>
> Here is what I did so far:
>
> For now I have the base library (still not in some public place just
> because I still didn't found one. But the license will be public
> domain.). I already have 3 functional filters.
>
> The library is being developed in C using test-driven-development. And
> the basic idea is that it takes a xlib XColor compatible pointer, see if
> it needs to be changed and then change it returning if the color has or
> has not been changed.
>
> So, what do others think about the idea?
>
> Which is the better way to integrate this into metacity and gnome?
>
> I was thinking composite management could help, but I'm not sure.
>
> Well, this is just a kick-off. If someone could offer some place to host
> the sources, nice (I just didn't want to start yet another project in
> sourceforge...)
>
> Thanks in advance,
>
> Daniel Ruoso
>
> P.S.: Please include-me in replies, I'm not subscribed.
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>