Re: Accessibilty module for colorblind people
- From: Daniel Ruoso <daniel ruoso com>
- To: Bill Haneman Sun COM
- Cc: gnome-accessibility-list gnome org
- Subject: Re: Accessibilty module for colorblind people
- Date: Tue, 10 Oct 2006 22:41:50 +0100
Ter, 2006-10-10 �15:57 -0400, Bill Haneman escreveu:
> Hi Daniel:
Hi... First of all, I'd like to thank you for you reply...
> 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.
This is fine, at least for Gnome. I usually don't have problems with the
usability of the software itself. The problem usually resides in reading
charts from the internet, or when seeing images that present some
information in the wrong colors. And that's why I'm attacking it from
the other side.
> 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.
I would be fine with that, actually. As far as the system is as useable
as without the magnifier. In fact, I don't have the most recent version
of gnome-mag here (my fault), but my user experience when trying it is
not so confortable. I should download the latest version to give it a
try.
> 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.
Agreed, except that the main problem is not with the applications that
are part of the desktop environment. gnome is already
colorblind-friendly as colors are not used as the only alternative of
information.
> Re-coloring the entire screen makes sense in some situations (but can
> produce ugly or unpleasant results sometimes).
Agreed also, and that's the point of having a keystroke to turn the
filter on and off.
> 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.
This raises the issue of gnome-mag being a composite manager itself, but
this is something to be discussed with the metacity team, not the a11y
team (I've just started a thread about it in metacity-devel-list).
> 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.
Indeed. This is something that should be discussed at some time...
> 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.
One way or another, this is my plan. libcolorblind is already an
independant project, and will continue to be. I'm just trying to figure
out how/where to plug it...
[]'s
Daniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]