Updated: Comment #66
Problem/Motivation
The color module allows users to change the color scheme within compatible themes. Choosing foreground and background color combinations which have a low contrast could make content inaccessible to users.
Proposed resolution
Detect low contrast background/foreground color combinations chosen using the color module and then warn users when they choose color combinations that have low contrast. The following luminosity algorithm can be used for the detection: http://splitbrain.org/blog/2008-09/18-calculating_color_contrast_with_php
(The W3C provides a recommendation for minimum accessible color contrast values here: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G18.)
To make this applicable to all themes and not just the default core theme, every theme should be able to specify which of their color field combinations should be tested for contrast (not all themes will have the same color fields, e.g. “Header background top” or “Footer background”). It was suggested that a way to make this dynamic would be to use an “luminosity_test” array of palette background:foreground color combinations that need to be tested. For example:
'luminosity_test' => array(
'titleslogan' => 'top',
'text' => 'bg',
'link' => 'bg',
)
would specify that the color values for the fields ‘titleslogan’ and ‘top’ should be tested against each other for luminosity. ‘text’ and ‘bg’, and ‘link’ and ‘bg’ will also be tested.
Perhaps this array should be placed within the $info array in the theme’s color.inc file, although in comment #60 @mgifford suggests “Theme name to _color_luminosity_test” for storing the array of colors to test (I’m not sure how one would decide what’s better).
Note on terminology and how theme information for the color module is specified:
Themes can specify any number of default fields to which colors can be applied (this set of fields is called a palette). These ‘fields’ are described in an $info array in the theme's color.inc file with a key mapping to a human readable label. Color schemes or palettes (also arrays) then define the default colors that should be applied to each field using the same key. Here is the start of Bartik’s $info array which specifies this information:
$info = array( // Available colors and color labels used in theme. 'fields' => array( 'top' => t('Header background top'), 'bottom' => t('Header background bottom'), 'bg' => t('Main background'), 'sidebar' => t('Sidebar background'), 'sidebarborders' => t('Sidebar borders'), 'footer' => t('Footer background'), 'titleslogan' => t('Title and slogan'), 'text' => t('Text color'), 'link' => t('Link color'), ), // Pre-defined color schemes. 'schemes' => array( 'default' => array( 'title' => t('Blue Lagoon (default)'), 'colors' => array( 'top' => '#0779bf', 'bottom' => '#48a9e4', 'bg' => '#ffffff', 'sidebar' => '#f6f6f2', 'sidebarborders' => '#f9f9f9', 'footer' => '#292929', 'titleslogan' => '#fffeff', 'text' => '#3b3b3b', 'link' => '#0071B3', ), ), 'firehouse' => array( 'title' => t('Firehouse'), 'colors' => array( 'top' => '#cd2d2d', 'bottom' => '#cf3535', 'bg' => '#ffffff', 'sidebar' => '#f1f4f0', 'sidebarborders' => '#ededed', 'footer' => '#1f1d1c', 'titleslogan' => '#fffeff', 'text' => '#3b3b3b', 'link' => '#d6121f', ), ), 'ice' => array( 'title' => t('Ice'), 'colors' => array( 'top' => '#d0d0d0', 'bottom' => '#c2c4c5', 'bg' => '#ffffff', 'sidebar' => '#ffffff', 'sidebarborders' => '#cccccc', 'footer' => '#24272c', 'titleslogan' => '#000000', 'text' => '#4a4a4a', 'link' => '#019dbf', ), ), ...
It was initially proposed that users be given the ability to switch between foreground and background colors. It was also proposed that users should be prevented from choosing color combinations with inaccessible contrast values, perhaps shifting to the closest accessible colors . It has been suggested that both of these proposals should not form part of this issue. Once the main issue identified has been committed, if required these should be made into separate issues. Although forcefully preventing users from choosing certain color combinations may not be the best idea.
Color contrast issues in core themes mentioned in early comments seem to be fixed.
Remaining tasks
- Make the changes suggested in comment #59
- Update the wording for the messages (see comments #63 and #64)
- Possibly include the contrast warnings in the page preview (See comment #63)
- Unit test for the new helper function,
- Functional test for the messages.
- Usability review on the proposed message texts.
- Document the color module’s ability to test for contrast issues, and how themers can specify which color combinations should be tested.
User interface changes
There will now be warning text that notifies the user when inaccessible foreground/background color combinations are chosen. The exact messages are still to be finalised. There could also be an indication of this in the image preview, also still to be determined.
API changes
- There is a new function _color_luminositytest that tests contrast.
- Themers using the color module can specify an array of colors to test in the $info array.
Please note that both of these changes have not yet been confirmed, but once confirmed, the information should be updated here.
Original report by @mikesmullin
color.module should have the ability to prevent colors that do not have the minimum required contrast for color-blind folk to read properly either a) provide a warning or b) automatically shift to the closest color(s) that still provide enough contrast when 'accessibility' mode is on or something.
along these lines there should be a feature for 'white-on-black' vs. 'black-on-white' foreground/background colors. currently there's no way to, for example, set the header gradient to a dark color and the text over it to a light color--allowing the user to change it to the dark text on light background if they want.