[Kde-accessibility] Re: Color problems [was: Re: KDElibs: KSystemTray: On window close dialog]

[Luciano Montanaro]

El Jueves 30 Septiembre 2004 06:25, David Johnson escribió:
> On Wednesday 29 September 2004 06:00 am, Olaf Jan Schmidt wrote:
> > It is perfectly fine to write styles that work for only a part of the
> > settings in KDE, but then they shouldn't be part of kdelibs and
> > definately shouldn't be default. Anyway, I think the styles
> > themselves are OK, it is only the 3D algorithm in Qt and/or kdelibs
> > that is broken.
>
> If all you're asking is to fix the bug in Qt, then I'm all in favor of
> it. Heck, I'll even help you code or test it. But while it will improve
> most styles, I doubt it will push them into the level of accessibility
> I think you want.
>
> > If you have a white background, then you can still see the frames.
> > Using a similar technique, you can make sure that they are visible
> > for dark backgrounds as well, without removing the 3D look of the
> > colors in between. There is no good reason why the algoriothm should
> > return black as a the lighter colour of black. If the algorith
> > returned dark gray, then everything would be fine.
>
> With a true white background you're losing half the frame/bevel
> information for most styles. A true black background would be the same
> even with your suggested fix.
>
> > I don't think it is asking too much to expect all parts of KDE to
> > work for disabled people. I do believe, however, that it is asking
> > too much of disabled users to work around bugs in KDE by changing a
> > lot of independent settings.
>
> If accessibility means that KDE users cannot have Plastik as their
> default style, even though they have been requesting it in hordes for
> over a year now, then I would have to say you are indeed asking too
> much.

I think there is no need for all styles to be designed for accessibility,
but having one style designed (or tweaked) for accessibility should be 
considered. And some tweaks could be applied to many styles, in fact,
since I think some accessibility requirements are usability enhancements 
too. E.g. most styles use pixmaps or fixed-size symbols for the checkbox, 
tree-list expander, radio box widgets. To be accessible to people with low 
vision, these element should be scaled up to match the font size. This is 
also improves the usability of the style, since it works better at font 
sizes different from the default. 
 
>
> These aren't bugs in KDE. You have identified a real bug in Qt, but that
> fix won't make all styles instantly accessible. That's because the
> styles aren't incorrect. You simply cannot draw a shadow on a black
> background and see it. Even with your suggested fix you're drawing very
> dark gray highlights around black widgets. That's very difficult to see
> with the best of eyesight!
>
> I have taken special care with my styles to make sure they work with
> darker color schemes. But very dark backgrounds are a special corner
> case. It's one that almost demands a separate substyle. That's twice
> the work.
>
> If (!verydarkbackground)
>  // code to draw the widget normally
>  // ...lighter highlights and darker shadows
> else
>  // code to draw the widget using a black background
>  // ... light highlights AND light shadows AND drop the gradients
>
> > > The solution is not to blame the styles, but rather to create a new
> > > style for use in situations that need high contrast dark color
> > > schemes.
> >
> > This is the usual reply, but no one has yet offered to write this
> > style. Another problem is that users with low vision will not know
> > which style to select, so KDE will still appear broken for them. This
> > is why at least the styles in kdelibs need to be fixed - if a fix in
> > the algorithm is not enough, which I expect.
>

> I would offer to do this, but I simply have too much stuff on my plate
> right now. Since I'm not too proud to turn down mercenary work, offers
> of monetary compensation would do a lot to change my mind. (Heck, last
> time I threw up that challenge someone accepted, so why not do it
> again? The worst that can happen would be howls of derisive
> laughter...)
>

I can't promise too much currently, but I am interested in modifying the 
style(s) I use to improve the issues above. I'd be interested in addressing 
accessibility problems, too. Is there a summary of the issues to consider 
somewhere? Is there an existing style that is a good starting point for 
further accessibility work? I think the classic highcolor would be a good 
candidate, but if there is some better starting point, please tell me. 

> Sidenote: If users with low vision won't know which style to select, how
> did they know to select a color scheme that wouldn't work with the
> default style? Your hypothetical problem could be solved, it seems to
> me, by making it simple to select an accesible style/scheme from the
> Desktop Settings Wizard. Then you can kill two birds with one stone.
>

Yes, an accessible pre-set should be available when installing KDE.
But is it possible to have one setting that is ok for most people with 
accessibility problems? Whithout knowing much, I'd try to assemble 
something like this:
Large fonts (how much?) is 14pt enough, or is 18pt better?
High contrast (inverted?)
Keyboard and mouse tweaks (which? maybe sticky keys, keypad mouse...)

The intention is to offer something that can be further tweaked by a large 
class of users with disabilities to match their needs.  

> > > > The currently algorithm for both shadow color and light effect
> > > > color is something like:
> > > > brightness = factor * brightness of background color
> > > >
> > > > This can be fixed by using an inverted algorithm for the light
> > > > effect color:
> > > > darkness = factor * darkness of background color
> > >
> > > Not quite accurate, but I get your point. I banged my head against
> > > this one in the past as well.
> >
> > Do you see any problems with this suggestions for intermedate
> > colours?
>
> After digging into the code I found that your suggestion doesn't reflect
> what's happening. The palette is built in
> KApplication::createApplicationPalette() using QColor::light() and
> QColor:dark(). So we're already using the inverted algorithm for 3D
> effects. QColor::light() multiplies HSV value by the lightness factor
> and QColor::dark divides HSV value by the darkness factor.
>
> The problem is only with black (zero value). One possible solution is to
> make an arbitrarily low HSV value the "floor" for the QColor
> calculations. It could be fixed in KApplication, but that won't catch
> all the instances of light() and dark().

-- 
Any sufficiently advanced technology is indistinguishable from a yo-yo
                                                                 - Enoch 
Root