Summary

Determining the colour contrast between foreground and background colours is a time consuming task, but is greatly aided by colour contrast analysers. The problem with colour contrast analysers is that they don't automatically go through all of the possible colour combinations in a document; instead, it requires a judgement call by the person evaluating the page to decide whether colour combinations look like they may be problematic, and then to enter those colours into a colour contrast analyser.

I've written a Firefox extension that reveals the colour contrast of all elements in the DOM. If you evaluate websites for colour contrast, this extension will be useful for saving you time, and also take out the guesswork required to determine which colours to test.

Author: Gez Lemon

Contents

Colour Contrast Analyser

The Colour Contrast Analyser Firefox extension lists colour combinations used in the document in a table that summarises the foreground colour, background colour, luminosity contrast ratio, and the colour difference and brightness difference used in the algorithm suggested in the 26th of April 2000 working draft for Accessibility Evaluation and Repair Tools (AERT). Each element is also listed with its parent elements, and class and id attribute values when specified to make it easier to locate the elements.

Only elements that contain text are listed. This avoids listing contrasts that could fail on colour contrast, but only contain elements where the styles are overridden and pass. For example, if the colour contrast for an li element is poor, but all li's for a particular list only contained anchor elements, then only the anchor elements are analysed. In the case of an element that contains other elements but also has text content, then the element is analysed. Duplicate elements that share the same parents with the same class and id attribute values are only listed once. This saves listing things like the li element more times than necessary.

When an element's foreground and background colour combination fail either the luminosity contrast ratio or the colour contrast algorithm suggested by AERT, the whole row is coloured yellow. To avoid showing information by colour alone, I've also added a thick border around the row to emphasise it. It's important to remember that both the luminosity contrast ratio or the colour combination algorithm suggested by AERT have never been recommendations; they're suggestions by two WAI working groups to help determine whether or not the contrast between two colours can be read by people with colour blindness or other visual impairments. The luminosity contrast ratio algorithm will become a recommendation when WCAG 2 becomes a recommendation if it is still listed in the guidelines.

Limitations

The colour contrast analyser only examines the difference between foreground and background colours for text elements, so won't detect scenarios where text is written over the top of a background image. The analyser also misses dynamic changes, such as hover effects.

I've tested the extension on a few websites, and it seems to be working reliably. If there is anything I've missed, or you can think of ways of improving it, then please email me or leave a comment.

The Firefox Extension

Download the extension from Mozilla's add-ons.

As with all Firefox/Mozilla extensions, you will have to restart your browser for the extension to be installed. Once installed, you can activate the extension by either right clicking on any web page, and select Colour Contrast Analyser from the context menu, or select the Tools menu item, and then the Colour Contrast Analyser menu item (Keyboard shortcut: ALT+T followed by C).

Updates

  1. Added ability to select type of test required (all tests, luminosity contrast ratio, or using the AERT colour contrast algorithm), following a suggestion from Jim Thatcher. (2006-02-13)
  2. Ignore elements that cannot contain text nodes (such as script), following a suggestion from Steve Faulkner, plus some optimisation of code. (2006-02-14)
  3. Added title attribute via the DOM, and added explicit colour options to the style sheet, following a suggestion from Paul Arzul. (2006-02-17)
  4. Fixed a display problem when the colour intensity for red, green, or blue was less than 16, reported by Steve Ferguson. (2006-02-18)
  5. Optimised the code, following a suggestion from Paul Arzul. (2006-02-21)
  6. Localised version provided by Steve Faulkner. Translations for languages other than English will be added as when they are received. (2006-03-02)

Translations

A special thank you to Steve Faulkner for coordinating the translations.

  1. Brazilian Portuguese, kindly provided by Mauricio Samy Silva. (2006-03-07)
  2. Japanese, kindly provided by Norio. (2006-03-08)
  3. Polish, kindly provided by Peter Mikolajski. (2006-03-23)
  4. Italian, kindly provided by Livio Mondini. (2006-04-03)
  5. French, kindly provided by Bérénice Mougenot. (2006-06-26)
  6. Russian, kindly provided by Dmitry Y. Krasnikov. (2008-07-08)

Category: Mozilla/Firefox Extensions.

Comments

  1. [colour-contrast-analyser-firefox-extension.php#comment1]

    Very nice Gez. I tested it with a number of sites, including some that claim to advocate accessibility but did not fare so well. They shall remain nameless.

    Also, I'm always on the lookout for Firefox extensions designed for Web developers. I hope you don't mind that I "Americanized" the spellings when I added CCA.

    http://loadaveragezero.com/drx/extensions#juicy:analyzer

    Posted by Douglas Clifton on

  2. [colour-contrast-analyser-firefox-extension.php#comment2]

    Hi Doug,

    Thank you for your kind words.

    Also, I'm always on the lookout for Firefox extensions designed for Web developers. I hope you don't mind that I "Americanized" the spellings when I added CCA.

    I don't mind at all, and thank you for the listing in the extension section *smile*

    Posted by Gez on

  3. [colour-contrast-analyser-firefox-extension.php#comment3]

    so won't detect scenarios where text is written over the top of a background image.

    But will detect problems for when CSS is on, and images are off. Nice extension.

    Posted by Big Mac on

  4. [colour-contrast-analyser-firefox-extension.php#comment4]

    Gez, another wonderful gift to accessibility. You rock! And ouch...I'm failing in areas that caught me be surprise. I've been using the "print the page on a black and white printer" test method...and your test is giving me lots of "fail" marks for my university's burnt orange against white.

    Some of my errors are for text that is offscreen and not meant to be seen by the human eye. Other errors are understandable and I'll review with my designers.

    But whatever am I to do with my burnt orange? There are not many colors that look good with #CC5500 (the official color of my uni).

    Any words of wisdom for me and my http://www.utexas.edu?

    Posted by goodwitch on

  5. [colour-contrast-analyser-firefox-extension.php#comment5]

    Wow, thank you for your kind words, Glenda *smile*

    But whatever am I to do with my burnt orange? There are not many colors that look good with #CC5500 (the official color of my uni).

    Just looking at the contrast, it looks fine to me. With the validators, it's a difficult colour to work with. None of the web safe colours provide enough contrast with that colour; black and white seems to be the closest. I would be tempted to get people with visual impairments to provide feedback on that particular combination before considering changing the colours.

    Posted by Gez on

  6. [colour-contrast-analyser-firefox-extension.php#comment17]

    This could be a useful tool but the results are not accurate. Running the tests on Malarkey's site reports white text on a white background.

    As Zcorpan points out, there is white text on a white background. This tool is useful for catching those types of mistake; Malarky could provide a background colour for the elements that contain text for when images are disabled.

    Posted by Gez on

  7. [colour-contrast-analyser-firefox-extension.php#comment21]

    Also, just noticed a couple of failed tests for this page including the footer text.

    Most of the failures are with the AERT algorithm, which I personally feel is too strict. HP recommend a colour difference of 400 or above, which is what I've worked to for the default style sheet. The alternative style sheet for this website passes all tests, including the stricter AERT algorithm. With the standard style sheet, it was only the footer that failed the lumonisity contrast algorithm, so I've changed that as I agree the contrast wasn't sufficient.

    Thank you for raising the point.

    Posted by Gez on

  8. [colour-contrast-analyser-firefox-extension.php#comment22]

    hi gez, great tool. *smile*

    i'm not seeing the "thick border" around the failure row. i think it's style should read:

    
    tr.failure
    {
      /* border: 2px solid #000; */
      border: thick solid #000;
    }
    

    what is Thumbs.db?
    - chrome/cca.jar/skin/classic/cca/Thumbs.db
    file magic reports it as a microsoft office document.

    the w3 style validator has 2 warnings for style.css
    - chrome/cca.jar/content/cca/stylesheet/style.css
    Line: 4 You have no background-color with your color: body
    Line: 32 You have no color with your background-color: tr.failure

    the generated html is missing a doctype, and it's title element is empty.

    it good to see you're using getComputedStyle() and getRGBColorValue().

    are there plans for a bookmarklet version?

    hope that helps,

    - p

    Posted by Paul Arzul on

  9. [colour-contrast-analyser-firefox-extension.php#comment23]

    Thank you for some great feedback, Paul.

    i'm not seeing the "thick border" around the failure row.

    Good point, 2 pixels isn't enough so I've updated it to your suggestion of "thick".

    what is Thumbs.db?
    - chrome/cca.jar/skin/classic/cca/Thumbs.db
    file magic reports it as a microsoft office document.

    I couldn't find this, but after further correspondence with Paul, I found the file and removed it.

    the w3 style validator has 2 warnings for style.css

    I've added the missing colours to the style sheet.

    the generated HTML is missing a doctype, and it's title element is empty.

    I've added a DOCTYPE and title element.

    are there plans for a bookmarklet version?

    I've sent an IE version to WAT-C for inclusion into the IE toolbar. I might do a generic bookmarklet at some point, but I don't plan to at the moment.

    Thanks again for the feedback, it's really appreciated.

    Cheers,

    Posted by Gez on

  10. [colour-contrast-analyser-firefox-extension.php#comment25]

    Hi Gaz,

    Setting the background as transparent in my style-sheets shows as #ffffff on the Contrast Analyser?

    The extension gets the inherited value when a value of transparent is provided.

    Posted by Gez on

  11. [colour-contrast-analyser-firefox-extension.php#comment27]

    Hi Steve,

    there seems to be a problem displaying color values. For instance #730d51 is displayed as #73d51

    Thank you for reporting the problem. I've fixed the code so that it display hex numbers correctly. Fortunately, the mistake was a presentation issue only and didn't effect the colour contrast results.

    Many thanks,

    Posted by Gez on

  12. [colour-contrast-analyser-firefox-extension.php#comment30]

    hi gez,

    a few more observations (for version 0.27):

    - the doctype is still not appearing in the generated html source

    - the title element appears twice now. once empty: <title></title>, and once as <title>Colour Contrast Analyser</title>

    cca is rather slow, try it on wikipedia. getComputedStyle is inherently slow, so what else can we do to speed things up?

    it's not much, but i'm getting about a +5% speed increase (measured using the venkman javascript profiler) by:

    - cloning objBody &
    - removing unnecessary regex calls

    browsers repaint the canvas after *each dom write*. a cloned node is no longer part of the document tree -- just reattach it when you've finished with that hairy table.

    you've got 7 fairly pricey regex calls to .match which you can remove by adding another property to objElementDetails (clearer), or more obtusely by making the get* functions return state info, like so:

    
    function getColourDifference(objForeColour, objBackColour)
    {
      var bFail = true;
      ...
    
      if (iColourDifference > 500)
      {
    
        bFail = false;
        ...
      }
      else
      {
        ...
      }
    
    
      return [bFail, strColourResult];
    }
    

    - in checkText, s* will always match (as * matches zero or more occurances). perhaps you meant s+ (one or more whitespace matches)?

    douglas crockford's javascript lint is always educational:
    http://www.jslint.com/
    documentation: http://www.jslint.com/lint.html

    i ran ccaOverlay.js through it. the main things it seems to dislike are:

    - line 17 character 2: Undefined variable: arElements
    - line 287 character 3: Undefined variable: objRGB
    : declare them as a local variables with "var"

    
    - instantiate new arrays/objects using array/object literal notation
    : var arElements = [];  // was: new Array()
    : arColour = [iRed, iGreen, iBlue];  // was: new Array(iRed, iGreen, iBlue);
    : var objElementDetails = {};  // was: new Object();
    

    - various helper functions (checkText, getColour, getLuminosity,
    getBrightness, getColourDifference, getParentElements, alreadygot,
    getBrowser, getColourParts, getHex) are used before being defined
    : move them to top of file?

    - line 190 character 40: Use '!==' to compare with ''.
    : if (arElements[iCounter].parents !== '') // if (arElements[iCounter].parents != '')

    - one line ifs without a following code block {}
    : a common source of errors

    - it wants the optional radix argument on parseInt passed as ecmascript v3 allows implementations to parse a string that begins with "0" as octal or decimal.

    it thinks you're defining certain variables twice (objChild, objElementDetails, iCounter, objP, objCode) because you declare them twice or more within the same scope. remember that unlike most other languages, javascript's scope is *not* limited by code blocks {} but only by function.

    (i find it best to put all variable declarations at the beginning of a function.)

    suggesion: is it possible to add named anchors or unique ids to each element so that the results table can reference them? this would makes it far easier to locate errors. (i think you'd have to put the results table on the same page then.)

    - p

    Posted by Paul Arzul on

  13. [colour-contrast-analyser-firefox-extension.php#comment31]

    - the doctype is still not appearing in the generated HTML source

    I've no idea why; if anyone else does, let me know.

    - the title element appears twice now.

    Fixed.

    browsers repaint the canvas after *each DOM write*. a cloned node is no longer part of the document tree -- just reattach it when you've finished with that hairy table.

    Cloning the node might be a good idea, but I need to check how that works with screen readers. I may be remembering incorrectly, but I'm sure there is an issue with cloned nodes added to the DOM not being communicated to AT.

    douglas crockford's javascript lint is always educational: http://www.jslint.com/ .

    That's useful - thank you. Some of the results are a bit subjective, but it looks to be a useful tool.

    i ran ccaOverlay.js through it. the main things it seems to dislike are:

    - line 17 character 2: Undefined variable: arElements
    - line 287 character 3: Undefined variable: objRGB

    Good catches

    : declare them as a local variables with "var"

    LOL - thanks

    A lot of the issues reported by jslint are about programming style (as mentioned in the documentation). I've made the changes that I considered important - the latest version at this point is 0.29. There will be more updates for localisation. I'll do some test with cloneNode to ensure it works as expected with assistive technology before doing anything else.

    suggesion: is it possible to add named anchors or unique ids to each element so that the results table can reference them? this would makes it far easier to locate errors. (i think you'd have to put the results table on the same page then.)

    The results table would need to be on the same page, which is something I want to avoid.

    Thank you very much for all the feedback, it's very much appreciated. Would you mind emailing me future suggestions for this tool http://juicystudio.com/contact.php ? I will announce any updates I make, but it saves bloating the page with large comment exchanges. I would have emailed you, but you've not provided your email address with your message.

    Thanks again for the great feedback.

    Posted by Gez on

Comments are closed for this entry.