By: Nigel Peck

December 2nd, 2002

Reader Rating: 7

Accessibility in Web design addresses the issue of creating Websites that are accessible to all users, regardless of physical ability or the way in which they use the Internet.

In this article we'll discuss the concepts surrounding accessible Web Design, the current initiatives to increase the accessibility of Websites, and the guidelines that you can use to make your site more accessible.

Why Accessibility Is Important

Why aren't all Websites accessible? You may be asking yourself why the issue of 'accessibility' even exists, and why all Websites aren't already accessible to all users. There are a number of reasons that explain the need for accessible design. Some involve disabilities that users may have, while others simply stem from the way different people choose to access and use the Internet.

Visually Disabled Users

Visually disabled users range from the colour blind, to the fully blind. These users can have problems understanding images that are not accompanied by a text description of what they show. Without a text description a user who can't see an image has no way of knowing what it is, or what it represents. Colour blind users may also have trouble discerning design elements (including text) whose colors are not sufficiently different from the elements around them (including the background or page colour).

Visually impaired users may also have problems understanding sites that are not built to accommodate "viewing" through a non-visual browser such as a screen reader. A screen reader is a Web browser that reads Websites out loud, thereby making them accessible to visually disabled users. Often a Website that looks nice visually can be a complete mess when it is listened to through a screen reader.

Hearing Disabilities

Similarly to the issues facing the visually impaired, are those that face Web users with hearing problems. Users with hearing disabilities have no way of understanding information that is communicated with sound. The simple solution is to provide an alternative that does not use sound, such as a text description or an image.

Physical Disabilities

If you are not physically disabled, it's hard to imagine how your online experience may be affected if you were. For instance, have you ever tried to use a Website without your mouse? Unless you were lucky with the site you visited, you probably found it very difficult. Physically disabled users are often incapable of using a mouse. Unless these users' needs are taken into account when you create Website navigation and input methods, physically disabled users may well find your site completely inaccessible.

Cognitive and Neurological Disabilities

Websites can be complex, and finding the information we want can be difficult for the most able of us. The situation is not helped by sites that use an overly complex design, inconsistent navigation, and distracting, repetitive animation. These design elements can compound problems for users with Cognitive and Neurological Disabilities, and can make some sites completely inaccessible for them.

Beyond Disabilities

As we have seen, using the Internet if you have a disability can be a difficult task. By observing and understanding the guidelines for accessible Web design, you can produce a site that serves its purpose and is accessible to all users, not just those without disabilities.

But it doesn't stop there. Accessible Web design has advantages for other users, too. These groups will benefit if you follow the guidelines to make your site accessible:

• Users of mobile phones, Web-TV and kiosks
• Low bandwidth users
• Users in a noisy environment
• Users with "screen glare"
• Users who are driving
• Users with a low literacy level
• Second-language access
• Users with different learning styles

Dealing with accessibility issues also improves:

• Page transmission and site maintenance
• Machine indexing of content
• Searching of content

The Marketplace

There's another reason to make your site accessible (if you need any more!). According to current figures, disabled users currently make up around 10% to 20% of the population in most countries. Increase that figure to represent the portion of your users who fall into the categories listed above, and you're looking at up to 30% of the market for your Website. If making your site accessible to 30% of the market doesn't persuade you that accessible Web Design is worthwhile, then you might as well stop reading now.

The average age of the population in many countries is also increasing. Aging results in a number of accessibility issues, including vision and hearing changes and declines in dexterity and memory. If your market includes a significant number of elderly visitors, then you can increase that 30% to a much larger percentage of users who will reap the benefits of accessible Web Design.

Legal Requirements

For certain Websites, addressing accessibility can be a legal requirement. This is usually the case for government sites, but can also affect others. For more information on the requirements in different countries see the W3C page Policies Relating to Web Accessibility [1].

Accessibility Initiatives

A number of groups around the world are working to increase the awareness of accessibility issues, and provide help to the authors of accessible Websites. These include the World Wide Web Consortium (W3C), the US Government and CAST/Watchfire. Let's take a look at what each of these groups has done in more detail.

Web Accessibility Initiative

Since 1999 the World Wide Web Consortium (W3C) [2] (the organisation that creates the standards for the Web) has been working on its "Web Accessibility Initiative" or WAI. The official mission of this initiative is:

The World Wide Web Consortium's (W3C) commitment to lead the Web to its full potential includes promoting a high degree of usability for people with disabilities. WAI, in coordination with organizations around the world, pursues accessibility of the Web through five primary areas of work: technology, guidelines, tools, education and outreach, and research and development.

The result of this initiative so far has been three sets of guidelines:

• Web Content Accessibility Guidelines 1.0 [3]
• Authoring Tool Accessibility Guidelines 1.0 [4]
• User Agent Accessibility Guidelines 1.0 [5]

The Web Content Guidelines are designed to show Website authors how to make their sites accessible. The Authoring Tool guidelines are for people who write programs that can be used to create Websites. The User Agent guidelines are aimed at those who create Web browsers. Let's look in more depth at the Content Accessibility guidelines.

Web Content Accessibility Guidelines 1.0

The Web Content Accessibility Guidelines or WCAG became a W3C recommendation on the 5th of May 1999 (becoming a W3C recommendation is an extremely tough and long process).

The purpose of the guidelines is to explain the accessible use of Web technologies for those who create Websites. This is achieved through 14 guidelines, with a total of 60 checkpoints that must be followed to ensure a site is accessible.

To accommodate the varying levels of effort people are willing to put in to making their sites accessible, the checkpoints are broken down into 3 different priority levels. The specification [6] lays out the three priority levels as follows:

[Priority 1]

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.

[Priority 2]

A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.

[Priority 3]

A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

For those who take the time to produce pages that conform to any of the above priority levels there is a matching set of conformance levels:

• Level 'A' -- All Priority 1 checkpoints are satisfied.
• Level 'Double-A' -- All Priority 1 and 2 checkpoints are satisfied.
• Level 'Triple-A' -- All Priority 1, 2, and 3 checkpoints are satisfied.

Pages, sites, or portions of sites that conform to one of the three levels may then display a logo, linked to the appropriate W3C explanation of the claim:

[7] - Level 'A'

[8] - Level 'Double-A'

[9] - Level 'Triple-A'

For full details of the conformance logos see the W3C WCAG Conformance Logos [10].

Alternatively, conformance can be specified through a text explanation such as:

The text must specify:

1. The guideline's title: "Web Content Accessibility Guidelines 1.0"
   
2. The guideline's URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505 [12]
   
3. The conformance level satisfied: "A", "Double-A", or "Triple-A".
   
4. The scope covered by the claim (e.g., page, site, or defined portion of the site).

The Web Content Accessibility Guidelines were developed by the Web Content Accessibility Guidelines Working Group (WCAG WG) [13]. The following W3C pages will be useful if you would like to produce pages that conform to WCAG 1.0:

• The Guidelines [14]
• A checklist of the checkpoints [15]
• Techniques for following the guidelines [16]

The US Government - Section 508

The US Government has endorsed the W3C Web Content Accessibility Guidelines by requiring that all federal Websites and sites that are under a federal contract must comply with the guidelines. More information can be obtained from Section 508 [17].

Bobby

While it is possible to read the Web Content Accessibility Guidelines and build your site to comply, wouldn't it be easier if there were a tool to test it for you? You've guessed it, there is: a product called Bobby was produced by a non-profit organisation called CAST [18] in order to test sites to ensure they complied with the guidelines. It is also aware of the conformance levels, and will tell you which level your site is at (if any).

In December 2001 Bobby also began supporting Section 508, which makes it the most complete accessibility tester available. In July 2002 Bobby was purchased by a company called Watchfire [19], who now look after the product.

Bobby has its own set of logos that work in much the same way as do the W3C logos:

[20] - Level 'A'

[21] - Level 'Double-A'

[22] - Level 'Triple-A'

[23] - For Section 508 compliance approved by Bobby

You can use Bobby in two ways. If you only want to test a few pages here and there it is available as a free on-line tool at http://bobby.watchfire.com/ [24] and works in much the same way as the W3C HTML validator (if you've used it). You enter the URL of the document you want to check and receive a report that details where you comply and where you don't. Because of the nature of the accessibility guidelines, it's not possible to check everything through a program, so you will still have to check some things yourself -- Bobby tells you what to check.

If you want to check many pages, the on-line tool has its limitations (you can only do a small number of checks per hour). In this case, you'd probably be best to purchase the downloadable version, so you can check as many pages as you like. At the time of this writing (November 2002) the price is just US$99.

A nice feature of Bobby is that for every guideline, advice is readily available on how to make your document comply, and why it's important for accessibility.

Over to You

For more information, these urls will give you a good start. Have fun making your sites accessible!

Further Information

• Policies Relating to Web Accessibility [25]
• World Wide Web Consortium (W3C) [26]
• Web Content Accessibility Guidelines 1.0 [27]
• Authoring Tool Accessibility Guidelines 1.0 [28]
• User Agent Accessibility Guidelines 1.0 [29]
• W3C WCAG Conformance Logos [30]
• Web Content Accessibility Guidelines Working Group (WCAG WG) [31]
• The WCAG Guidelines [32]
• A checklist of the WCAG checkpoints [33]
• Techniques for following the WCAG guidelines [34]
• Section 508 [35]
• CAST [36]
• Watchfire [37]
• Bobby [38]

[1] http://www.w3.org/WAI/Policy/
[2] http://www.w3.org/
[3] http://www.w3.org/TR/WAI-WEBCONTENT/
[4] http://www.w3.org/TR/WAI-AUTOOLS/
[5] http://www.w3.org/TR/WAI-USERAGENT/
[6] http://www.w3.org/TR/WAI-WEBCONTENT/
[7] http://www.w3.org/WAI/WCAG1A-Conformance
[8] http://www.w3.org/WAI/WCAG1AA-Conformance
[9] http://www.w3.org/WAI/WCAG1AAA-Conformance
[10] http://www.w3.org/WAI/WCAG1-Conformance.html
[11] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
[12] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
[13] http://www.w3.org/WAI/GL/
[14] http://www.w3.org/TR/
[15] http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html
[16] http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
[17] http://www.section508.gov/
[18] http://www.cast.org/
[19] http://www.watchfire.com/
[20] http://bobby.watchfire.com/
[21] http://bobby.watchfire.com/
[22] http://bobby.watchfire.com/
[23] http://bobby.watchfire.com/
[24] http://bobby.watchfire.com/
[25] http://www.w3.org/WAI/Policy/
[26] http://www.w3.org/
[27] http://www.w3.org/TR/WAI-WEBCONTENT/
[28] http://www.w3.org/TR/WAI-AUTOOLS/
[29] http://www.w3.org/TR/WAI-USERAGENT/
[30] http://www.w3.org/WAI/WCAG1-Conformance.html
[31] http://www.w3.org/WAI/GL/
[32] http://www.w3.org/TR/
[33] http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html
[34] http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
[35] http://www.section508.gov/
[36] http://www.cast.org/
[37] http://www.watchfire.com/
[38] http://bobby.watchfire.com/