Skip to content →

Tag: WCAG

Check My Colours

Published 26 September 2009 by Rocío

www.checkmycolours.com is a website for you to easily check if the colours on your website are accessible.

This tool takes all of the references to colour from your web page including your CSS and nicely compares the background colours to the foreground colours. The report that gets tabulated shows very bluntly what instance is acceptable and what instance is not. The system analyses three things: Contrast Ratio, Brightness difference, and Color difference. By clicking on the rows, it also allows the user to find another colour that would replace the current one. Unfortunately, this feature is a little hard to click on.

The site can give the user an idea of what is lacking in terms of colour accessibility, but does not offer a comprehensive understanding of what the guidelines are. Explaining what the categories and the numbers mean might clarify the systems results.

Let me demystify it for you.

Contrast Ratio: Contrast is measured using a formula that gives a ratio ranging from 1:1 (no contrast) to 21:1 (maximum contrast). AA and AAA refers to the level of priority. Level AA are strongly recommended (mininum contrast is 4.5:1) to allow most users accessibility. Level AAA are suggested (mininum contrast is 7:1) to allow some users accessibility.

Algorithm for luminosity contrast ratio in Web Content Accessibility Guidelines 2.0 Glossary.

Brightness difference: Another formula that evaluates the difference between the background brightness, and the foreground brightness. This should be greater than 125.

Color difference: This formula refers to the difference between the background colour and the foreground colour  and should be greater than 500.

Formulas are explained in the document Techniques For Accessibility Evaluation And Repair Tools.

The limitation of these types of applications is that we cannot check the colour balance from images.  This is one of the reasons that it is not recommended to make any text into images. They cannot be viewed by external reading programs.

Leave a Comment

Reviewing an authoring tool

Published 17 June 2009 by Rocío

I was going to do an evaluation of an authoring tool, but the WAI have thought of it already at www.w3.org/WAI/AU/2002/tools.

I found that the reviews were all a little outdated and I didn’t get a definite conclusion from any review. So I finally decided to go ahead and check out an authoring tool myself. I went for the markup editor developed in collaboration with the W3C, Amaya. It’s a WYSIWYG editor/browser. Many distributions are available. I will be looking at the Windows one.

I opened an existing file that I know is made to standard and it came out all distorted. I then created a page from scratch. I must admit that I’m not used to any kind of authoring tool. I have been using Notepad++ for a while. So it was a little strange. At first it took me some time to get used to the application itself, but after a while of playing with it, it was fairly simple to use. I did a trivial page with a menu, an unordered list, a form and an image.
Page done with Amaya

Page done with authoring tool Amaya
Page done with authoring tool Amaya

Formatting done to some text resulted in inlining style, there were extra open and close paragraphs, inserting the image required to enter an alternative text, and as for the other elements they were pretty intuitive.

It’s clear that you still need to know some basic concepts in web standards to make any web page complaint or accessible. This tool might be good for someone just starting, but I think I’ll just stay with my simple text editor.

Leave a Comment

Evaluating a website for accessibility

Published 15 June 2009 by Rocío

The W3C has extensive information on how to properly evaluation a sites accessibility. Here are the underlining steps to ensure that your evaluation is full-proof:

For a preliminary review, select a page that is representative of the whole site or that most people will see. Try to choose a page that has tabular data, images and scripts. And then:

  • Examine this page for alternative text,
  • Divs instead of tables for page layout,
  • Use the keyboard instead of the mouse for navigation,
  • Test with different font-sizes and screen resolutions.

The Firebug and Web Developer extensions in Firefox will make your life easier in accessing the code and disabling images and even resizing your browser size. It might be a good idea to try a screen reader, and not to mention an Web accessibility evaluation tool like AChecker. These will enhance your understanding of the sites limitations and successes.

Another important part of evaluating a site is to get people with disabilities involved in the process. Some may have insights that other users will not.

For a complete procedure of website evaluation you have to go to the W3C – Web Accessibility Initiative page.

Although a little outdated, the WAI also provides a comprehensive checklist of accessibility guidelines (WCAG 1.0) and an useful template for the final accessibility report. They really thought of everything!

One Comment

Examples of assistive technologies

Published 24 May 2009 by Rocío

So I saw this story on the news by Chris Brown and was happy to learn that assistive technologies are being researched actively in Canadian Universities.  The University of Victoria has a unit named CanAssist, they develop technologies and provide services for people with disabilities. Naturally this is relevant in terms of web accessibility because a lot of these devices interact with computers. I encourage you to read their technology showcase as it describes the uses of these technologies by people with different types of disabilities. For example, instead of using a mouse for navigation, it is possible to use one’s mouth. And as the news piece revealed, the team of researchers have created a device that detects the movement of the pupils and allows the cursor to move accordingly. Pretty ingenious!

It is obvious that these researchers and developers are not waiting for websites to get their act together in terms of web accessibility, but it just proves that this demographic has the possibility to access the world wide web. We can all make it a little bit easier for researchers to make these products more effective by implementing WCAG.

Watch the video entitled “Communication Research” at the CBC. Unfortunately, this video has no caption and thus not accessible.

Leave a Comment

Useful before and after demonstration

Published 22 May 2009 by Rocío

The W3C have a super neat online demonstration of visually representing web accessibility. The inaccessible pages have several “barriers”, key elements that make the page inhospitable. For example, the before home page demonstrates a lack of alternative text for each image, an inconsistency in the content order, a negligence with headings and lists, an inaccuracy with link texts and font sizes.

Even by visually comparing both inaccessible and accessible pages you can see the subtle, yet important, differences. I suggest to examine one page at a time. Carefully look at the before and after of the home page, then read the “accessible barriers”. When you understand the “barriers” then go on to the next page.

If you want to see how to go from a non-compliant site to an accessible one, you need to read this document, the before and after demo at: http://www.w3.org/WAI/EO/2005/Demo/Overview

Leave a Comment