Governments and now Educational Institutions, mainly Universities are taking the matter into their hands.

Blogs like www.prettysimple.co.uk/blog and contests like at www.accessibilityinfocus.co.uk encourage and pursue the issue in terms of content, design and context. I even came across a guild for accessible web designers. It is hopeful to see that web professionals consider web standards as an important facet of the web experience.

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.

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

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.

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!

Contact page before

Contact page after

They don’t look different, but I did change the code.

Here’s what I did:

• I started by getting rid of the tables for layout purposes. I know!!! It’s all gone now.
• Then I added the language to the html tag, lang=”en-US”, like this <html xmlns=”http://www.w3.org/1999/xhtml” lang=”en-US”>
• I gave a more complete title to each page, like “Nadia Stevens Jin Shin Do Bodymind Acupressure Montreal”.
• I repositionned some divs and wrapped them properly. Some classes and ids were not correctly placed, so I had to fix these. For instance, I had the same id used several times in the same file, so I changed these to classes.
• Some images had misleading or inaccurate alternative text. Instead of “Fire” as the alt attribute for a chinese character representing fire, I wrote “Fire character”. In the instance where I had images that were not content related I made them blank text, like this: alt=”".
• I got rid of widths and height attributes.
• The menu of the page was not in a list, so a placed it in an unordered list.
• For the maps, I added an onfocus attribute to every onmouseover attribute  and I added an onblur attribute to every onmouseout attribute.

The first page took me about 3 hours, additional pages took me 1 hour to 2 hours to renovate in the same way.

Ok so this site was easy to do because I had already a lot of div’s in the first place, but it really gave me an idea of how many things need to be thought of while in the process of revamping a site. This work is meticulous and a little repetitive, but if done with methodology, making any site accessible can be pretty painless.

[Intro music] Welcome to podcast three of Thinking Accessible. On today’s podcast, I will talk to you about my four golden rules for web accessibility.

Rule number 1:

Provide alternative text for non-textual content. What do it mean by this? Images are non-textual content. Audio and video are non-textual content. So for each of these elements you need to provide a text alternative. So for images in the HTML code you have to write an alternative tag to it. So in the tag of IMG for image you have to add ALT. for alternative text and here you would put basically a general idea of what the image represents.For audio feed, like for example this podcast, it would be nice to put a transcript of the audio because some people might not be able to hear it. And for video, you should put obviously captions for all the text (speech) in the video. Sure these are not easy to do, there are time consuming, but in the end it is good, for one, the person that cannot hear or see you media and also for search engines, because they will actually have the textual reference for these medias. So it’s a win, win situation.

Rule number 2:

Make it simple and consistent. Making your website simple will help people with cognitive impairments, elderly people and new web users that are not used to big and elaborate websites. Consistency is also important because if you have a lack of consistency your user might be confused, won’t know what’s going on with the website, might be lost. So we want to minimize this because if a user feels frustrated in your website, they are more likely to leave that website and go somewhere else. You can make your website simple by simply (sorry for this repetition) using normal vocabulary that anybody can understand. Do not be too verbose and just be clear with what you can to express. Consistency is to basically keep the same layout through out your website and you should be fine.

Rule number 3:

Colour contrast. In order to make your website legible it is important to consider colour. For example if you want to have a black background you shouldn’t really consider a colour for the text to be dark grey because this will be illegible for a lot of people. For me this rule is just for you to use common sense. I mean if you think that the colours you have chosen for the foreground and the background are not going to be legible or not easily legible by let’s say your grandmother, then don’t use them because it won’t be legible for a lot more people.

Rule number 4:

The last rule. Respect those HTML tags. Ok, so here it is. If it’s a <p> tag, then it’s a paragraph, then use it as a paragraph. If it’s a <table> tag, then use it as a table. Tables should (only) be used for tabular data, for example a data in a spreadsheet and not for layout, not for your page layout. (Use CSS instead!)

So those are my four golden rules for web accessibility. Yes, I know, there’s more to it than that, but for just a quick rundown of the essential ideas in web accessibility, these four simple rules are a major step forward.

[Exit music] Well that’s it for today’s podcast. That was podcast three for Thinking Accessible. My name is Rocío. Until next time!

Audio from ccMixter entitled “Café Connection“ by Morgantj under Creative Commons.

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

I came across some CMS that have accessibility integrated into the system in an article written by the National Center on Disability and Access to Education named NCDAE Tips and Tools: Content Management Systems & Accessibility.

They explain the major challenges that people with disabilities face while using a regular CMS and give us advice on how to choose a responsible system. Most of the systems they recommend have an accessibility page stating there attempt to respect accessibility guidelines. This is valuable information that can help anyone accessing the site. Read this article before considering any CMS.

Simply put, they are a set of guidelines for web development and web designing. It represents the good practices of the profession. When I started creating websites I had no idea their were rules, but now that I know they exist and I know why I need to use them I cannot code without them. There are several sets of guidelines around the world, but the most widely known is the World Wide Web Consortium (W3C) web standards. Found at www.w3.org. This site is a little overwhelming for someone just starting to look into web standards, so I will attempt to provide some basic guidance and to list the most important elements.

Web standards are important because without them web accessibility is impossible. Web Standards make it easier for usability and even for code maintenance, reduce bandwidth use and increase cross-browser compatibility. Another great advantage of web standards is SEO (search engine optimization). Sure you can get all these even if you don’t follow the standards, but it will cost you.

The only disadvantage that I can think of, even if it’s not a valid reason to avoid web standards, is time. Time to learn it, time to implement the guidelines and time to test it.