Accessibility for Web Developers

Introduction to Accessibility

Developers put a lot of effort into ensuring their sites can be viewed in outdated browsers, but all too often ignore newer browsers, or worse still, a whole range of visitors. Accessibility means access to information for all. Information to all, regardless of the device used to view the document, or abilities of the visitor. You're extremely proud of your latest masterpiece. The choice of colours is striking, the layout fits perfectly on your screen, but how does it look on a Personal Digital Assistant (PDA)? How does it look to a colour-blind visitor? Does it read correctly using assistive technologies, such as screen reading software? Can a visitor navigate the site without the use of a mouse? Is the site usable when JavaScript and images are switched off in the browser? Accessibility is about usability. The formula is simple - if your site isn't usable, it won't be used.

Don't think in the terms of whether or not your visitors have disabilities. If your Markup restricts access, the disabling factor is in the design of your site. If the door to a house is 6 feet off the ground with no steps, the positioning of the door is the disabling factor for people attempting to gain entry to the house. People could still get in, but they would have to be determined. The same analogy applies to Web sites. Don't rely on your visitors being determined - make it easy for them.

Visitors read pages in a variety of ways. They may skip around the page, or look for specific information within the HTML structure. This is why standards are so important, as it allows visitors to seek out specific information in a standard way.

Factors that may Impede Visitors

There are many factors that can impede access to your site, ranging from physical disabilities, to environmental noise. Does your site cater for people who are visually or hearing impaired? Have you considered visitors who have difficulty reading and comprehending text? What if the visitor isn't using a traditional input device such as a keyboard or mouse? Would a visitor with a text-only browser, or PDA be able to use your site? Will visitors wait for the content to download on a slow connection? What about visitors who disable popups, or are working in noisy environment? The list is endless, and it's your duty as a developer to ensure that access to the site isn't hindered by any of these factors.

These factors do apply to you. If I had £1 for every time these factors were dismissed when I've mentioned them to someone, I would now have £12. You can't assume all your visitors are using high-resolution monitors, and accessing your site over broadband. You have a moral, and in certain circumstances, a legal obligation (certainly if you are in the United States or United Kingdom) to ensure your site is accessible.

The Web Accessibility Initiative

The Web Accessibility Initiative (WAI) is an initiative from the World Wide Web Consortium (W3C) that defines standards to ensure your site is accessible. They provide a checklist of points to address through the Web Content Accessibilities Guideline (WCAG), to ensure that your site complies with their accessibility guidelines. The checkpoints are all given a priority, which ranges between 1 and 3 depending on the importance of the checkpoint. For a site to be considered accessible, priority 1 checkpoints must be addressed, priority 2 checkpoints should be addressed, and priority three checkpoints may be addressed.

Conformance to Level "A" means that all priority 1 checkpoints have been addressed, Level "AA" means that priority 1 and 2 checkpoints have been addressed, and Level "AAA" means that priority 1, 2, and 3 checkpoints have been addressed.

Web Content Accessibility Guidelines 1.0

The guidelines fall into 14 areas, summarised below.

1. Provide equivalent alternatives to auditory and visual content.
2. Don't rely on colour alone.
3. Use markup and style sheets and do so properly.
4. Clarify natural language usage.
5. Create tables that transform gracefully.
6. Ensure that pages featuring new technologies transform gracefully.
7. Ensure user control of time-sensitive content changes.
8. Ensure direct accessibility of embedded user interfaces.
9. Design for device-independence.
10. Use interim solutions.
11. Use W3C technologies and guidelines.
12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
14. Ensure that documents are clear and simple.

Prority 1 checkpoints have been marked with a icon in the following pages.