The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Tag: wcag

JQGTK+ Color Selector

Posted in hyperweb by Adam
Posted on

Last month I wrote about the issues with color. Today I’ve put up a color selector based on the GTK+ Color Selector.

Last month I wrote about the issues with color.  Today I’ve put up a color selector based on the GTK+ Color Selector.  You can try a demo at Sequlr: Color.

The basic idea was to first recreate the GTK+ Color Selector with canvas, and then add a filter and the compliance information to it.

It’s decent, and although I found a few other color selectors that tried to improve the ability to choose compliant colors, I didn’t come across one that used this method.  Also, those that want to can use it as a widget in their own projects.

It should run okay on the newest browsers, though it may be sluggish on older ones, especially on slower computers.

Thanks for reading.

The Woes of Color

Posted in software by Adam
Posted on

Colors are difficult to work with, especially for accessibility purposes.

As anyone that’s watched this blog when it’s changed, or looked at Sequlr knows, I’m not the most gifted person when it comes to picking colors.  Part of that is the fact that not all color combinations even work to begin with.  There’s this notion of contrast, and without contrast you simply cannot have a foreground and background at all.  The WCAG 2 guidelines for color contrast makes picking colors something of a minefield.

Many websites (I might even guess a majority, but I haven’t done any serious sampling) completely ignore WCAG/color contrast, assuming all of their users have perfect vision.  They are more concerned with the visual appeal of their design than the functionality.  This goes even for very prominent websites and those that at least pay lip service to accessibility.

But even for the few, the proud that make earnest attempts to comply, to contrast correctly, the obstacles are considerable.  Consider Mozilla Firefox, which is currently in the late beta versions of its fourth release.  They have a CSS color, GrayText, which is hardcoded and bad for accessibility in certain circumstances.  In the case I noticed, it’s used for the hovered link, now that the status bar is going away.  Of course, they shouldn’t be trying to indicate placeholder or non-standard text by making it gray, but it wouldn’t be so bad if they derived its value from the OS theme.

And there’s the second hit: the OS likely doesn’t provide a specific color for this use case.  It probably doesn’t provide guidance for link/visited link colors either.  The OS justification for this is likely that adding more color choices for the theme would complicate it.  That’s true, but you have to choose your direction of complication: either provide the choice that can be ignored by the user or end up with the application developer painting themselves into a corner.  In the latter case you end up harming your users anyway, as they may find their theme incompatible with a variety of software despite it being an otherwise usable theme.

My own experience with color has been that it’s very difficult even if you ignore accessibility.  If you do take contrast into account, it’s harder because you have to pick some colors and then tweak them or at least check them for proper contrast.

I think the solution is better allowance for user choice in colors.  At the OS level, as I’ve noted, but these color choices need to bleed through to the web.  The web application should be able to get a set of colors the OS theme uses, and apply them correctly to the presentation.  This would make the web blend better with the desktop, and it would improve the accessibility of the web a bit.  The other change needed is for the web to get over art.  Where the goal is art, the web can keep going, but where the goal is actually to present information, the tendency for art to trump function is alarming and harmful to the platform.

Selah.