Quantum Gypsies

How I built a web site and learned to love Cascades

The limits of access

One of the key ideas of the web is that information is freely available to everyone and everyone should mean as close to everyone as possible. I had never considered this issue until I started researching for this site. How would people with disabilities access the site? How would non-English speakers be able to understand the fabulous content they find here? What about people too poor to afford a computer?

The last point is being addressed in a small patchy way with the advent of netbooks, the much hyped $100 notebook. The only contribution I can make to that effort is to ensure that each page is as lean as possible, so that those with limited bandwidth can still access them successfully.

The display of web pages in different languages is something that is technically much easier if the content is served from a database. A user entered language choice on the home page can then drive text selection. For a simple HTML and CSS site like this one, translation into multiple languages is not only difficult, unless you know a friendly United Nations translator, but increases the page count by leaps and bounds.

So apart from a few particular items like the Italian phrases on the Leonardo page, you will have to wait for translations until I have mastered serving text from a database. In the meantime, there are a number of sites that offer translation services, either of words, phrases or complete web pages; here are a few of them, but there are many others

This leaves me with addressing the problem of access for disabled English speakers and even here I can only address a very limited range of disability; blindness or partial sightedness. My source for how I should approach accessibility is the Web Content Accessibility Guidelines version 2.0, published by the World Wide Web Consortium

A clean layout

Web browsers already offer help for minor sight problems, with the option of changing the text size. What I as a page designer have to do is to ensure that if text is enlarged to 200%, then a line of eighty characters can still be read without either horizontal scrolling or having completely fill the screen. This is simply a matter of letting all text float on the page so that changing text and or window size still leaves a readable line of text. I do set a minimum page width restriction, so that images and text do not get completely divorced, but at any width greater than the minimum, everything shuffles around to fit.

For some people the only way to surf the web is via an audio or braille screen reader and for these devices some careful thought needs to be given to the design of a page. The first thing I needed to do was to check that if the page was read mechanically from top to bottom, left to right, then the content would appear in a logical order and this is easily done by commenting out the CSS file reference and checking to see that the page is perfectly understandable.

It is also important to achieve a reasonable consistency between pages, so the navigation is always top left for instance. Speaking of navigation, keyboard control for all navigation needs to be available and for that I am relying on the browsers to be consistent in what they provide as access key alternatives to mouse clicks. The TAB and RETURN keys do allow navigation across the whole site, but I haven't yet found a way to change the rather dim highlighting that shows the current focus of the keyboard.

I have to provide understandable content and that means taking care to avoid acronyms and jargon as well as writing in a clear straightforward manner. However, when writing about creating web pages, it is impossible to avoid some acronyms. I also try to break up each page into semantically complete sections with headings.

However, my most important task is simply to run a spell check and a visual inspaction each time I make a change to any text. It is tedious, but I don't know any other way of avoiding typing mistakes from preventing a page from being machine read. That still leaves the problem of regional differences in the spelling of English words, particularly between North America and Europe and, so far I have no answer to that. The page header does have an EN language tag, but that doesn't specify which flavour of English is being used, so I need to research other tags that I can insert to help a screen reader to interpret the page correctly.

A colourful tag match

The next accessibility requirement is to provide a <title> tag for each non-text content element. The key word here is content; if an image is simply used for page decoration then it would be clearly absurd to title it. The title does require some thought: For menu items and in line links it is pretty clear that it should explain that the cursor is over a clickable area and what the target of that click is. For images, it is necessary to strike a balance between meaning and brevity. I have also provided a title to the unordered list on the Leonardo Da Vinci page. The reason is that the list is in Italian, with an English translation next to each item, so the screen reader will come across an Italian word on an English page and, hopefully, the title will explain why.

The final aspect of my site design that needs careful thought is the use of colour. The w3c site gives recommended contrast levels between page elements and background, but I have not yet found any way to test the colours on my page against those recommendations. What I do instead is to closely inspect each page under difficult lighting conditions, like full sunlight or a strong lamp, to check that no areas disappear into the background. I only use a small palette of colours and have got rid of the swirling colours that appeared in the first incarnation of the site, so I think everything is reasonably legible.

Where now?

The outstanding accessibility problem I have at the moment is how to provide a lexicon of any acronyms used on a page and the only idea I have is to provide a link from every acronym to its definition, which will be a lot of work but may be necessary. It will have the upside of forcing me to consider carefully whether I need to include an acronym.

After that I have to find the web addresses of organizations that test web sites for accessibility and report on which elements need more work. Hopefully, I can achieve a good accessibility rating, but it will probably be a matter of closing in on that goal, rather than jumping straight to it. In the meantime, I am glad to have acquired some understanding of the problems so that I can design future pages with accessibility built in, rather than tacked on at the end.

Last updated 15 January 2009