What Makes A Site Accessible?
Accessibility is about making sure all the information on your website is available to all users, regardless of any disability they may have or special technology they may be using.
“Accessibility involves making allowances for characteristics a person cannot readily change”’. (Building Accessible Website, Joe Clark)
Why Bother?
Fairness and equality
The simplest and most direct answer to this is that if your site is inaccessible to users with disabilities, you are excluding a section of the population from your content. If your students cannot access the course materials, they could be placed at a distinct disadvantage and their coursework could suffer as a result.
Accessibility benefits usability
Many site designers and developers drag their feet and grumble when asked to make their site accessible. There is a mistaken perception that “accessibility” means “dumbing down” the site—that they won’t be allowed to use any graphics or any multimedia. Frequently, websites address accessibility by making a plain, text-only version of every page and labelling it “accessible”. This does no one any favours—it requires the webmaster to maintain twice the number of pages, and provides an inelegant solution that lumps all disabled users into the same category.
The reality is that accessibility is a way of enhancing your web page, and it can be done seamlessly without taking away from the design. Many accessibility recommendations and guidelines actually improve the integrity of your code and the overall usability of your interface. Usability is, simply put, how easy it is for people to use your site.
Anything you can do to improve accessibility can also improve usability for people without disabilities, for online courses or any other kind of website. Consider these examples:
- you have made the menus consistent on every page— now everybody has an easier time finding their way around your site, because the buttons are always in the same place;
- you have made sure your font size can be adjusted— now older readers with poor vision can increase the size of the text to see it better;
- you have set a unique page title for each page—now search engines can more accurately display your pages in their search results;
- you have added a text description for each image— now someone browsing with images turned off can tell if they are missing an important diagram;
- you have added captioning to a video—now a student using a computer in a public lab can watch it too without needing sound;
- you have added an audio reading of an important passage—now a student who learns better aurally can enjoy the reading as well.
Legal reasons
As we have already discussed, many institutions are obligated to provide accessible content according to national laws.
Accessibility Standards
There is a set of guidelines developed by the World Wide Web Consortium (W3C), a group that establishes specifications, guidelines, software and tools for various aspects of the Web, including file formats and scripting languages. One W3C program is the Web Accessibility Initiative (WAI), whose mission is to help make the Web accessible to people with disabilities. The WAI has developed the Web Content Accessibility Guidelines (WCAG) to address the accessibility of information in a website. These guidelines are what we will be using in this chapter, and should always be consulted if you are ever in any doubt of the best technique or the correct syntax of a tag. They are fairly technical, and not a quick read. However, two simplified versions of these guidelines organized by concept do exist as Appendices of WCAG 1.0 (1999a and 1999b), both as a checklist table and as a list of checkpoints. At the time of writing, the current version of the guidelines is WCAG 1.0, and WCAG 2.0 is under review.
These guidelines, relevant to online content developers, help to ensure that Web resources are accessible. However, there is a need to recognize the limitations of these guidelines as well as the available checking tools (Ivory & Chevalier, 2002). Kelly and Sloan (2005) talk about the difficulties of implementing the guidelines, summarizing the concerns in regards to ambiguity, complexity, logical flaws and the level of understanding required to implement them.
Despite the difficulties with the guidelines’ implementation and reliability, and the necessity of manual checking for accessibility, WCAG are very helpful in the initial stage of developing an online resource, as a quick checklist of obvious things that need fixing. The guidelines should not be taken as the only set of criteria that needs to be considered. A wider set of issues must be addressed, some of which could be in conflict with the guidelines.
Priority and Levels of Conformance
Each checkpoint has a priority level assigned by the working group based on the checkpoint’s impact on accessibility.
- 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.
Depending on which priority checkpoints a site meets, it can claim to meet a particular level of conformance.
- Conformance Level “A”: all Priority 1 checkpoints are satisfied.
- Conformance Level “Double-A”: all Priority 1 and 2 checkpoints are satisfied.
- Conformance Level “Triple-A”: all Priority 1, 2, and 3 checkpoints are satisfied.
Testing for Accessibility
There are a number of tools available to help you check some of the more technical aspects of your website to see if it meets accessibility standards. One of these is WebXact Watchfire (webxact.watchfire.com/), previously known as Bobby. It is a very handy tool for double-checking that all your images have alt text, or that your data tables are properly labelled.
But these tools are not the whole picture. An accessibility analyzer like Watchfire cannot tell you if the descriptions of your images make sense to a blind user, or if your page titles are meaningful. Your website needs to be considered from a human perspective, and many of the WAI guidelines ask you to examine the context and meaning of your content more carefully.
