High contrast and ignore colours

Recently, I’ve been doing some accessibility fixes for a project I maintain — the LACE Evidence Hub (I talked about it). I am also doing some accessibility evaluations of other sites.

And so, I’ve been revisiting some work I did previously for Open Media Player on fixing high-contrast related bugs and issues.

Before we get into the meat of the post, I’ll recap why high contrast and ignore colour settings matter. People with low vision use a number of techniques to read text and web sites. They may use a screen magnifier, or zoom in with their browser. And, those users who struggle to perceive contrast, may employ the high contrast settings built into operating systems including Windows. Or, they may set their browsers to ignore the colours and styles specified by a web site.

Under such settings, background images used on buttons and elsewhere will disappear, and subtle borders which help to demarcate regions of a page can become invisible. Suddenly, an apparently beautiful page becomes much harder to comprehend!

Obviously, it’s better to consider this situation upfront, and take care how background images and other styling is used. However, if you find that you need to fix a site after the fact, is there anything you can do?

Why … yes!

This accessibility fix comprises threetwo parts.

The Javascript

This is one of the rare cases where we can detect how the user has set up their computer. First, the small Javascript script, ignore-color.jquery.js, can be employed. It runs a test periodically by creating a hidden HTML element, setting its background colour, then detecting if the specified colour is still in use. If the user has used any sort of high contrast or “ignore-colour” setting in the operating system or browser, then the assigned colour will not be used – the test will “fail”.

The Javascript uses the result of the test to set a class on the <body> of the web page – either ignore-color or no-ignore-color. The Javascript is fairly lightweight – the only cost is that the test is run every 4-8 seconds via setInterval(). (As far as I know, there is no alternative – ideally one would detect a Javascript event fired when the user changes their configuration.)

Note, the ignore-color Javascript is based on work by John Snyders.

The styles

While the first part of the fix is fairly generic, the second part is specific to each web site. The body-class set by the Javascript can be employed in CSS stylesheets, to take remedial actions.

A lot of the CSS fixes will involve colours and colour combinations. Your initial reaction may be – “Help! I don’t know what specific settings or high-contrast theme the user has chosen. So, how do I select safe colours?”

The answer can be found in the use of operating system styles. These are a set of pre-defined terms in CSS, that tell the browser to use your computer’s operating system colours – whatever they may be.

An example follows from the LACE project – note this is applied to SVG, hence the use of stroke:

.ignore-color svg #sandisplay .link {
        stroke: Highlight;

Highlight is one of the pre-defined system styles, which produces the green bars in the Sankey diagram on the right of the first screen shot, in high contrast mode. In “normal” mode, the bars in the diagram are a light grey.

Screen shot 1 - high contrast Sankey SVG

The next CSS example is applied to form fields, and uses the pre-defined term ButtonText. Note, the border-style property must be inset to overcome a Firefox restriction or bug.

/* Firefox requires "inset" in ignore-color mode for form fields. */
.ignore-color input, .ignore-color textarea {
        border: 2px inset ButtonText;

And, here’s a screen shot showing the result of the fix, again on the right. As you may be able to see, the edges of the form fields are more noticeable, after the fix.

Screen shot 2 - ignore-colour form & video

So there you have it. Re-usable Javascript, and an example of CSS stylesheet fixes.

Not, pretty, but pragmatic accessibility fixes for high contrast and ignore-colour settings.

Now. Go experiment!


Update, 5 April 2016. I propose that there are actually three components:

  1. The Javascript detailed above, generic to any Web site;
  2. A generic CSS stylesheet that is applicable to any site — this would reset borders on form input fields, and include other fixes;
  3. CSS styles that are specific to a particular web site — examples of some specific styles are above.
Loading comments ...