general accessibility issues

Construction of this page was helped enormously by the site, "Dive Into Accessibility", which I would suggest is compulsory reading here. The WebAIM site is also very good.

Making your page more accessible to those who have problems using everyday browsers like IE is not just "political correctness". Anyway, that execrable term is just a substitute for thinking. If you make something in offline life, such as a building, more accessible to those with mobility problems (those in wheelchairs, the elderly, the blind), you make it more accessible to everyone, don't you? Implementing some of the suggestions given on this page can only enhance the quality of your site, and for those with aspirations of "professionalism" in web design, they should be obligatory. Unfortunately, many of the so-called "professional" sites out there ignore them... but that's an indictment of their designers' attitude, not of the techniques to be described. As the virtual lecture noted, "disability" is as much caused by society's failure to deal with diversity as it is caused by an illness. We may also move in and out of states of disability - anyone who breaks their leg skiing will find out about some of the accessibility problems which affect public space. Break your "mouse arm" and you'll discover similar things about the online world.

(Image from http://www.mcevoyengineering.co.uk, who construct this kind of thing...)

In any case, if your pages are not accessible to the disabled, you are now breaking the law. The 1995 Disability Discrimination Act (DDA) and the 2001 Special Educational Needs and Disabilities Act (SENDA) - amongst others - have been used to bring civil proceedings against companies whose web sites are not accessible to disabled users. But it's also worth realising that accessibility problems can cover several things, and only the first two are considered "disabilities" offline:

• Users with vision problems, who may use non-visual browsers. Note that many people who are "blind" have some vision, and might be able to read web pages using "everyday" browsers if text size is large - note the condition of colour blindness as well
• Users who cannot use a mouse and are restricted to the keyboard or voice input into a computer (see below)
• Users "handicapped" by unreliable and/or very slow phone or Internet connections, whether because of where they live or the quality of their equipment
• Users who simply choose to use less sophisticated browsers due to personal choice or the age of their computer equipment
• Users for whom English (or whatever other language the page is written in) is not their first language
• Users who lack confidence with information technology generally.

All of the above may have problems reading your web site if you ignore accessibility issues. All of them could potentially be helped to do so.

One thing worth realising is that writing pages accessible to all is really just the same as writing them for diverse browsers. Even if a non-visual browser, for example, would not normally be used by anyone with good vision, it's still just another browser. Therefore, the first step towards accessible web design is to write well-formed code. Code validators will help you out here.

However, well-formed code is only a start. All of the following will also help make your page accessible to one or more of these groups. Most have already been covered elsewhere, so links are provided.

• Keep your pages - and especially your images - small in memory terms.
• Write for as many different platforms as possible. Make your pages cross-browser compatible, including for text-only browsers, and validate your code.
• Don't demand that people upgrade their browser, download some new plug-in, or change their screen settings if they want to view your site. (If you don't agree with this, see the rant at the bottom of the page on text-only browsers.)
• Try and avoid long, uninterrupted blocks of text, and try to format your pages so text doesn't extend completely from one margin to the other. Use white space.
• Never remove the users' ability to resize your text. The only possible exception is on page headings and only then if they're already very large (at least 18 points).
• Use alt attributes on every image (but keep the value empty if the image is purely decorative).
• Ensure you include the <!DOCTYPE> declaration and a notification of the page's language and alphabet (via the lang attribute) on all pages.
• Use web-safe colours. Choose combinations that read clearly, and avoid red/green together.
• Make sure your <title> tags have meaningful content.
• Don't "fake" one tag with another: for instance, make sure your headings are real <hx> tags, not <p> tags with a different, larger font in them.
• And a couple of things for advanced techniques that we haven't discussed yet, but there's no harm in mentioning them: ensure you have text alternatives for all image maps and any other advanced navigation techniques, and provide label attributes in all form elements. Also make sure you use frames properly, which means with great discretion. More details will come in those lessons.

back to the top

keyboard-only browsing

This topic deserves its own section. When you use a mouse you are able to "focus" on any part of the screen. This gives you a huge amount of flexibility. But not everyone can use a mouse, due either to blindness, or mobility problems in their arms (including RSI). Or people simply choose not to use one, to avoid too much strain on the wrist, thereby helping to avoid the aforementioned RSI. If you want to use the keyboard to focus on a particular bit of the screen, then, you need to have told the browser that is a part of the screen worth focussing on.

There are other options here but allow me to note two ways in which this can be done. The first is to browse by heading: in Opera you can press S to skip forward a heading, and W to skip back one.

The second is by link: in IE, press Tab to "cycle" through all the links on a page, and Return to activate the link on which you're focussed. In Opera, press Ctrl+J to "reduce" a page to a list of its links (a marvellous feature!). This is why you should ensure all text within <a> tags makes sense out of context, giving the readers a good idea where the link is going: avoid "click here!". (This stuff has already been discussed, on the page on hypertext and navigation tips - check back there for more details.)

There is an attribute which can also help out here. This is the accesskey attribute which can go inside <a> tags. accesskey takes a value that represents a key on the keyboard. If the user then presses Alt plus the defined access key, the browser will "focus" on the link where that accesskey attribute appears. (That's the Alt key on the keyboard by the way, nothing to do with the HTML attribute.)

To illustrate: all the links back to the home page on this site are coded as follows:

<a href="index.html" accesskey="1">teaching materials home page</a>

Try it now if you like. Press Alt+1 and the browser will focus on the link: you can tell this if you look at the status bar. Then press Return and the browser will then follow the link.

It is now the accepted convention to always code accesskey="1" into links that return you to the home page of a site. Similarly, accesskey="2" is used for "skip navigation" links (see the page on non-visual browsers). If you use others, that's fine, but you should write some kind of accessibility document for your site which any interested visitors can access from the front page and in it, note what access keys exist.

Back to the top

Back to the menu for lesson 6