Unplug your mouse. Now try browsing the Web. It’s not easy, is it? Yet this is what millions of users have to do each day, due to disabilities leaving them unable to use a mouse. Elsewhere, because of poor sight, many rely on screen readers that literally read out all of a Web site’s content, while others cannot use conventional equipment, instead relying on single-switch devices, akin to using only the mouse, but in a very limited capacity.
Although such Web users are a minority, estimates suggest that almost nine million people in the UK have some kind of “physical or mental impairment” that has a “substantial and long-term adverse effect on his or her ability to carry out normal day-to-day activities”. This is how the Disability Discrimination Act 1995 defines disability – and this act is a benchmark against which lawsuits may be judged.
If you’re wondering “what lawsuits?” we’re thinking of the inevitable ones that may follow Web designers that continue to avoid the issue of accessibility entirely. Despite legislation already being in place to deal with inaccessible Web sites, and literally millions of potential users having some kind of disability, most sites fail to deal with accessibility issues at all. Even after blind person Bruce Maguire’s high-profile court case against the Sydney Organising Committee (which led to a damages payment of 20,000 Australian dollars after the Web site was judged to not provide access to all), most designers seem to ignore the issue and hope it will all go away. But it won’t.
Luckily, the basics of Web accessibility isn't rocket science. Many designers are put off by the available tools, which are either terribly expensive (such as most screen readers), or unreliable (such as Bobby, an online service that aims to test Web pages against accessibility guidelines, but that unfortunately only does so with limited success). These issues are further compounded for Mac users, because none of the common screen readers are available for Mac OS X, and few run reliably under Virtual PC. (Hopefully, Apple’s integration of screen reading technology into Tiger will be the much-needed boost Mac users have been longing for in this area.)
Armed with the knowledge of how to make a site accessible (see the links at the end of this article for some useful further reading), you can at least make a definite effort to make a site accessible – and that is the main thrust of accessibility requirements at present. With no major test cases to go on in the United Kingdom, and legislation being vague on certain details, it can be surmised that smaller companies may have little to worry about in a legal sense – although their Web development in future will most likely have to be accessible – and that even large companies may have a few lines of defence, even if in the strictest sense of its wording, the DDA applies to any UK company offering a service. However, even if lawyers aren’t breathing down your neck, it makes sense to make online services available to all – after all, the more potential customers you have, the more money you’re likely to make.
The freely available Opera browser’s User Mode enables you to check some accessibility aspects of your Web sites – useful, seeing as screen readers tend to be prohibitively expensive
The first thing you need to know in this field is that accessibility cannot somehow be “bolted on” to a Web site. Accessibility is something that needs to be considered at the start of a project, although there are steps you can take to at least improve Web sites that already exist. Using little-known HTML attributes such as tabindex and accesskey, you can set an item’s tab order and access key value respectively. The first of those enables a designer to set the tab order of items on a Web page, thereby avoiding the random tabbing that often becomes a soul-destroying experience of jumping to almost every link on the page until the target one is reached. Similarly, the accesskey attribute provides a method of activating or highlighting a link (depending on the browser’s behaviour) via a modifier key (usually Control on Mac and Alt on Windows) and the accesskey value. Of course, this is of use not only to those with disabilities, but other users, too. Many choose to use the keyboard more than the mouse, and if access keys and tabindex usage become commonplace rather than a rarity, this will provide everyone with an alternate method of navigating the Web.
This “better for everyone” idea is also true elsewhere: for instance, using a caption element for a table provides the user with a description of its contents, whereas a table on its own may be meaningless. However, some elements and attributes provide more than just a visual clue. For screen readers, alt text – either providing the description of an image or an indication of its function – is essential. Omitting alt text means a screen reader will simply say “image” or the image’s file name, which is of no use to anyone.
A better foundation
Some accessibility improvements require rather more work than slapping on a few extra attributes, though. Tabular data is typically formatted using HTML tables, but few designers make use of table header cells, instead using table data cells to house all content. But by restructuring the table using table header cells, a screen reader will read each value in context (header/data, header/data), making everything meaningful for someone using such a device. Perhaps more importantly, the entire layout construction of Web pages should be addressed when taking into account accessibility. Screen readers care not for how a page is supposed to “look” – they merely read code from top to bottom. Therefore, information must be ordered in a logical manner in the actual code. If there are many links in the navigation bar, including the option to skip to the content can be a godsend for screen reader users; and to achieve this and a logical, flexible layout, the use of CSS rather than tables for page layout is a good idea.
As we said earlier, though, software to test the accessibility of sites can be expensive and little is available for Mac users. However, Opera can help – its User mode includes options for tweaking the visible output: for instance, its “Accessibility layout” option removes some formatting and shows accessibility controls (such as access key values); select “Disable tables” as well and all table formatting is removed, enabling you to see whether site content is navigable and logical without them; with the addition of the “Emulate text browser” option, you can also check whether your alt text is in place and suitable.
Try using your site without a mouse, and then without a keyboard. Imagine navigating it one word at a time – is the content still usable? Can you access everything you need to via all methods, or are some important items effectively invisible? Are links providing information of where they lead to, or do many of them just state: “click here”? If the latter is the case, you need to change things: screen readers users cannot easily access content around individual words, so “click here” on its own becomes meaningless and out of context; furthermore, many screen readers place all links at the bottom of the page, leading to dozens of orphaned “click here” links – infuriating for users).
But all this is, in many ways, just the beginning. The advice in this feature will get you started, and is a good foundation for creating accessible sites, but it’s just the tip of the iceberg as far as Web site accessibility is concerned. For more information about guidelines and tips about accessibility, check out the W3C and RNIB links below.