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