Web Design Small Cover

Buy the PDF of
Web Design:
A Complete Introduction

See the book at amazon.co.uk or amazon.com

Related Site

Web Security Topics

Related Books

Secure Communication Cover

Securing A Server Cover

Tips on Designing for Accessibility

Accessibility is for Everyone

Never assume that accessibility is only about catering for some special group of people. It is not about catering to one particular group (for example, blind and partially sighted people) nor is it about catering for people who are not “normal”. Anyone can experience accessiblity problems at any time, and almost everyone will experience some problems eventually. To take a simple example, a broken wrist is a common injury among young and fit people (especially sports players) which, if suffered to the dominant hand, will immediately cause physical accessibilty problems, and it can happen to anyone. When thinking about visual accessibility, remember that the percentage of people using the Internet who are aged 40 and over is still climbing rapidly, and those who are younger today will be older in due course. Although accurate statistics are not easy to find, in Europe and North America the majority of this age group already have access to the Internet and many use it very actively. But this age group, comprising hundreds of millions of people, typically suffers some degradation of eyesight, and may need to blow up font sizes. Every young user who lives to middle age will become one of this “group” one day. So accessibility isn’t just for some people, it’s for everyone, and must be a top priority in every design. And make sure that your design considers all types of accessibility problems, and doesn’t just focus on one, which can lead to some serious errors in design.

Accessibility Enhancements for Firefox

The Firefox Accessibility Extension is a Firefox add-on which provides many useful facilities, both for people with accessibility problems and for Web designers wanting to check the accessibility of their site. For designers, it provides a quick way of invoking the W3C validation services, various options for simulating small screens and magnifiers, replacement of images and embedded objects with the textual alternatives (if any) that would be used by a screen reader, and a way of selectively disabling styles, among other features. For people who have trouble using a mouse, it provides a means of skipping between heading elements, displaying access keys and producing lists of links and headers for quick navigation. For people with poor eyesight, it can create high contrast versions of the page, as well as providing buttons for increasing and decreasing the font size.

The Accessibility Extension is not perfect. The interface is not perspicuous, and appears to duplicate several of its functions in different places. There is a lack of focus, with some of the facilities not seeming to be directly related to accessibility. At the time of writing (late November 2006), the extension does not work with the recently released Firefox 2.0. Despite these shortcomings, installing this extension turns Firefox into a much more useful browser for people with accesibility problems.

Alt-text for Logos

Checkpoint 1.1 of WCAG 1.0 says ‘Provide a text equivalent for every non-text element’, and tells you to use the alt attribute for img elements. This implies that if you have a company logo on your page, it needs a text equivalent in the form of an alt attribute to satisfy this checkpoint. WCAG 2.0 takes a less hard line. Its success criterion 1.1.1 includes, as its last case, ‘If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, it is implemented such that it can be ignored by assistive technology.’ In practice, for XHTML documents, this means using an alt attribute whose value is the empty string "". This is better than providing a non-empty alternative, since if an image performs a purely decorative function, screen reader users don’t need to know about it, and hearing the textual alternative spoken is a waste of their time.

The key point here, though, is whether a logo is purely decorative or not. You might think that if a logo is a graphic and if the site is clearly identified in a heading or early in the text on the page, the logo could be considered redundant so that it could be treated as pure decoration. However, if the logo precedes the navbar, as it usually will, it is likely to be the only means of identifying what site the visitor is on before the navbar is read out by a screen reader. For this reason it is necessary to provide alt-text for the logo which clearly identifies the site on every single page, unless there is some other form of site identification that will be read by a screen reader as soon as it reaches the page. Remember that a visitor may have come to any page of a multi-page site by following an external link, and will not necessarily have visited the site’s home page first. You must also remember to provide a skip-link on every page too, so that someone using a screen reader doesn’t have to hear the logo’s alt-text time and time again as they move around the site.

If there is a link to the home page on the logo, a textual alternative is required for that link. In any case, the text should convey the information that the logo conveys to sighted visitors, and not describe its appearance. Nor is it necesssary to state that it is a logo, as that does not convey useful information to a blind visitor. So for example, instead of ‘Desperate Software logo’ (a description of what would be seen), a logo with a link on it should have the alt-text ‘Desperate Software home page’ (a description of the link), and a logo without a link should have alt-text something like `Desperate Software’s Web site’ (text telling the visitor where they are).

Assessing Accessibility Problems

Although there are WCAG guidelines provided for making sites accessible, there will sometimes be cases when you aren’t quite sure whether or not some feature of a site is fully accessible, or perhaps whether or not the guidelines apply. In these cases where you have to make some kind of decision yourself, it is helpful to ask yourself “Is this feature of the site provided by some alternative means?”. The difficulty is remembering and understanding all of the kinds of barriers to access that users may experience. Broadly however, these can be grouped into problems with vision (including colour), problems with hearing, problems with physical mobility (especially problems with hands and arms), cognitive problems, and special conditions such as photosensitive seizure disorders. So you should simply ask yourself whether a person with each of these types of difficulties with access could recognize and use every feature of your site. If the answer is no, you should provide an alternative which they can use. This is not difficult to do, but it can be hard to remember when you are busy creating a site. It is important to make an effort to remain aware of the problems that will be faced by some visitors to your site, so that you can ensure that you do not erect unnecessary barriers to access.

Colour Blindness Testing and Image Correction

It is not necessary to abandon the use of full colour in Web design, only to make sure that all content is clearly recognizable and conveys its meaning to all users. For designers with full colour vision it can be difficult to assess how a coloured design will appear to someone with colour vision problems, so it is best to use some kind of aid. As we mention elsewhere, the fallback is to put your screen into greyscale in order to assess contrast. This is a valuable quick aid, but does not provide a simulation of what someone without full colour vision will see. If you are working on Mac OSX, Sim Daltonism is a useful little freeware application for testing anything on your screen against different colour vision problems. Vischeck is another excellent tool, which can be used either on the Web (it will upload any of your image files for testing) or downloaded as a Photoshop plugin for Windows or Mac. There is a lot of useful information and some excellent visual examples elsewhere on the Vischeck site, and they include an application that corrects images for colourblind users. Remember that in any group of 100 people of European or Asian racial origin, there will almost certainly be some people with defective colour vision. However, in a group of people of African, Aboriginal or South American origin, the number is likely to be much smaller. In all cases, incidence is very much higher in males.

High Priority Page Elements

Some visual elements on a page should always be considered of higher priority than others. These are the elements without which the visitor cannot make proper use of the site. They include all navigational features and all functional elements, for example “Submit” buttons for forms, and anything that has to be clicked to continue with a process such as shopping, paying or viewing another page. This is not just a matter of accessiblity but of general usability for all sighted visitors, and you will be doing your client a disservice if you design a site where these elements cannot be quickly and easily found. It is surprising how often these elements are not readily visible on the page. A shopping site that we used recently, for example, has text for such important functions as “add to basket”, “proceed to checkout” and “cancel” in light grey on a white background, in a small font size, and in a not very obvious position on the page. When designing a page these navigational and functional elements should be considered first, and their placement, their size and their appearance, including colour and contrast, must all be designed for maximum visibility. (For further thoughts on this, see Visual Hierarchies under Visual Communication tips.)

JavaScript

Don’t fall into the trap of assuming that, just because some assistive devices do not support it, JavaScript cannot be used in accessible sites. What the relevant WCAG 1.0 guidelines requires is that you ‘Ensure that pages are usable when scripts […] are turned off or not supported.’ This means that you can use JavaScript, as long as there is still some way of making the page work without it.

Some JavaScript has no effect on accessibility. For instance, if you want to gather data about visitors to your site using Google Analytics, you must include a small script on every page. This has no effect at all on how the page works, it just sends some information to Google. Other scripts can be positively beneficial to accessibility. For instance, JavaScript is the best way of implementing a stylesheet switcher. /Scripts can also be used to create lists of abbreviations, which can help people with short-term memory problems to understand a page better. Far from avoiding JavaScript, you should seek to use it in such ways, but you shouldn’t use it to provide essential functionality that is not provided any other way.

Long Pages

Long pages cause difficulties both for people with physical problems and for screen readers. Even a minor injury or RSI in the hand or wrist can make scrolling painful and difficult, and it is very tedious for people using screen readers to have to listen to long passages of text they cannot skip. Long pages offer poor usability generally, as content may get divorced from what preceded it and from material at the head of the page, including the navbar. The simple solution is to only create short pages, and you should aim for this wherever possible. If the content on a page demands the extra length, then it is necessary to provide a means for the user to jump to the part of the page required and back again, or to see just the part of the page they are interested in. There are various ways of doing this, including using a simple list of links at the head of the long content, and using a pop-up or drop-down menu (providing it is fully accessible).

Advanced screen readers provide their users with a quick way of skipping to the next header (h1, h2, ... element). The Firefox accessibility extension mentioned above adds this facility to Firefox. If you use headers to mark the beginning of each section of your page, you enable people using screen readers to skip from section to section, without having to provide an ugly collection of internal links at the top of the page – which will itself require some means of skipping past. Each of the tips on this page begins with a level 2 header, so it is possible to skip directly to the next tip. (Yes, we know we haven’t implemented this on some pages of this site yet, but it’s coming soon!)

PDF Accessibility

In the book, we have only discussed accessibility in the context of Web standard technology. However, many sites provide longer documents in the form of PDF. Adobe have a section of their site dedicated to PDF accessibility. Most of the things you can do to make PDF documents accessible are similar to those you use to make Web pages accessible, including providing alt-text for images and including navigational aids. The most important thing you need to do to make PDF accessible is to make sure that you generate tagged PDF. This is what allows screen readers access to PDF content. Generating tagged PDF is usually as simple as making sure that the appropriate option is selected when you create the PDF output. There are additional steps that you can take, which are fully described in the document Create Accessible PDF Documents with Adobe Acrobat. (Note that this link points to a version of the document that relates to Acrobat 7. There is not, as yet, an updated version for the recently-released Acrobat 8.) Some of the techniques rely on having Acrobat Professional, and even if you do have this program, fixing accessibility problems must be done a page at a time, so it can be quite time-consuming.

Physical Access Problems

If you have never had any personal experience of limited physical access, it can be helpful to simulate restricted access in order to understand better how it affects a visitor’s interaction with a web site. Unless you are ambidextrous, the simplest way of doing this is just to put your dominant arm in a sling, or otherwise physically restrict it so that you cannot use that hand at all. Now try surfing the Web and doing all the things that you would normally do, including filling in forms, scrolling pages, etc. Although you cannot experience the pain involved in using injured hands and wrists this way, you should get a feel for the way this kind of restriction affects interaction with sites, and the sorts of improvements to design that would help you get around better.