Note: This document is a
draft and should not be referenced or
quoted under any circumstances.
$Date: 2006/02/06 22:59:09 $ [changelog]
The first step in effectively addressing Web accessibility barriers is understanding the basic principles. WAI Resources on Introducing Web Accessibility is a collection of resources that highlight the basic principles of Web accessibility and some of the issues for people with disabilities on the Web. It is important to be familiar with some of these resources before attempting to retrofit a Web site for accessibility.
While implementing accessibility on an existing Web site may seem overwhelming at first, there are different approaches to make the process more efficient and cost effective. For example, there are often simple barriers that are easy to remove and that are repeated on several instances across the Web site. Identifying and removing such barriers first may rapidly enhance the overall quaility of the site. This document provides considerations and tips to help plan a project to improve the accessibility of an existing Web site. Also refer to the following related documents:
- Implementation Plan for Web Accessibility - lists considerations for implementing accessibile Web sites, many of which also apply to removing accessibility barriers on an existing site.
- Techniques for Web Content Accessibility Guidelines 1.0 - provides guidance for satisfying the requirements defined in Web Content Accessibility Guidelines 1.0 (WCAG 1.0).
Note: once a decision to improve the accessibility of a Web site is taken, it is often useful to inform the users by providing an "accessibility statement". This will help users to manage their expectations of the level of accessibility on the Web site and potentially encourage them to send feedback and suggestions. The statement should be linked from the home page of the Web site and must be accessible. It should outline the main problems known about the Web site, and the commitment to improve them. Where possible, it should also provide a timescale for implementing these improvements as well as an alternative means of contact, such as a telephone number or postal address.
Understanding the issues and identifying the barriers on an existing Web site is essential to plan the accessibility enhancement of the site. Conducting a Preliminary Review of Web Sites for Accessibility provides a quick overview of the level of accessibility on an existing Web site. While this review will not identify all the accessibility barriers or provide detailed results, it is easy to perform and gives a rough idea about the scope of the accessibility barriers on the Web site.
The following resources help carry out a more detailed analysis of the specific accessibility barriers on an existing Web site:
- Checklist of Checkpoints for WCAG 1.0 - lists the checkpoints of the Web Content Accessibility Guidelines 1.0 by priority level and topic.
- Conformance Evaluation of Web Sites for Accessibility - addresses scoping the evaluation, using tools, and manually evaluating pages.
- Involving Users in Web Accessibility Evaluation - helps to better understand experiencial accessibility barriers and potential solutions.
- List of Web Accessibility Evaluation Tools - collection of tools that can assist to evaluate and repair Web sites for accessibility.
Ideally, a comprehensive evaluation that combines a conformance evaluation and user testing of the accessibility features on a Web site is carried out. However, for first steps in reducing accessibility barriers on an existing Web site, some shortcuts can be taken to address the most severe barriers first. For example, not every page needs to be evaluated. Selecting a representative sample of pages will often highlight key issues that are common across the Web site. The sample should contain pages with a variety of each feature (such as data tables, forms, or scripts), pages from each developer or development group, and pages generated from each template. A combination of Web accessibility evaluation tools and less formal, small-scale user testing of accessibility features can also be lucrative at this stage.
Depending on the size and complexity of the Web site as well as on the approach used to evaluate its accessibility, large amounts of findings could be reported back. While this amount of results may seem overwhelming, careful prioritization can help manage addressing them effectively.
Prioritizing by Barriers
One aspect of prioritizing accessibility improvements is by their relative impact on accessibility. Consider the following questions:
- What is the impact on people with disabilities?
- The impact on accessibility can be generally determined by the WCAG 1.0 Priority Levels. Also results from evaluating with users with disabilities can provide insight about the impact of barriers on a specific Web site.
- Is there a policy requirement to address?
- In many cases site-wide or legal policies may introduce obligatory requirements. These requirements may be bound with certain deadlines, and they may map to selected WCAG 1.0 checkpoints or priority levels.
- How much effort is required to repair it?
- The time, cost, and resources required for repairing barriers varies greatly based on parameters such as the skills of the developers. Some lower priority problems are very easy to repair and it is often most efficient to address those first, rather than delaying any further.
Prioritizing by Pages
Another aspect of prioritizing accessibility improvements is by determining which pages to work on first. Consider pages that have the greatest impact on the Web site. These are often:
- Templates that impact all or many pages.
- Elements that impact all or many pages (for example navigation bars and scripts).
- Style sheets that impact all or many pages.
- Home page, which is often the first entry point to the site.
- Most important pages, and the path to get there from the home page:
- Pages and functionality that might be particularly useful for people with disabilities, such as search features, contact page, and site map;
- Content of particular importance for equal opportunity, such as job opening listings or legal information (such as terms and licenses);
- Pages and functionality that serve the main purpose of the site, and the path to complete any transaction that serves the same purpose.
- Frequently-used (high traffic) pages, and the path to get there from the home page.
Determining the source of accessibility problems helps in defining an effective plan to sustainably address them. Consider the following questions to help identify relevant sources of accessibility barriers on an existing Web site:
- Do the authoring and development tools support accessibility?
- Does an accessibility policy exist and is it being implemented?
- Do the developers have sufficient skills in Web accessibility?
Utilizing Adequate Authoring and Development Tools
Authoring tools (such as editors and content management systems) have a significant impact on the accessibility of Web sites. The document Essential Components of Web Accessibility describes the role of authoring tools during the development process and the effect of insufficient support for accessibility. Consider the following potential options:
- Upgrading - some authoring tools provide better support for accessibility than others, refer to the document Selecting and Using Authoring Tools for Web Accessibility for more information.
- Configuring - often accessibility features are not enabled by default or need to be optimized for increased accessibility support on a specific Web site.
Note: Web accessibility evaluation tools can also be utilized to help identify and reduce accessibility barriers. The document Selecting Web Accessibility Evaluation Tools provides guidance for finding suitable tools for an existing Web site and development environment.
Developing and Implementing an Accessibility Policy
Developing Organizational Policies on Web Accessibility helps to instruct and raise the awareness of authors and developers who are involved in producing content on the Web. It is also important to ensure that the policies are being implemented, possibly by introducing development guidelines and quality assurance measures. For example, improving evaluation and testing througout the development process reduces the production of inaccessible content that may need to be repaired at a later stage. Generally it is far more efficient to evaluate the accessibility of solutions (possibly involving users with disabilities) early on in the development process rather than patching less optimal and more demanding work-arounds at a later stage.
Improving the Expertise of the Web Developers
Implementing Web accessibility is usually the responsibility of several stakeholders. For example, the authors who develop Web content and the programmers that develop Web applications have a shared responsibility in producing accessible solutions. Therefore, each individual involved in Web production needs to be aware and have a basic understanding in Web accessibility. For first steps in implementing Web accessibility, it is often best to combine educating in-house staff with bringing in outside expertise. Consider the following approaches to address the acquisition of additional expertise in Web accessibility:
- Training Staff - training in evaluating Web content for accessibility, developing accessible content, or learning about the accessibility features of authoring tools leverages the skills of staff.
- Hiring Experts - a qualified accessibility expert can
save time and effort in the long run by providing:
- the latest best practices for accessibility solutions;
- first-hand experience of how people with disabilities interact with the Web.
- Engaging Consultants - experienced consultants can compensate for missing skills within the staff. For example, additional skills in CSS is a common need.
Extensive evaluation reports should contain detailed analysis of the accessibility findings and recommendations for further actions. These recommendation are often an ideal starting point in implementing accessibility repairs. The following tips may help better manage the repairs:
- Separate Tasks
- Often it makes sense to separate and assign tasks according to expertise of the staff. For example, adding image descriptions requires some knowledge of the content and minor skills with the authoring tool. However, reparing scripts that generate dynamic content requires programming skills.
- Optimize Processes
- Accessibility can be seen as a quality assurance process. Timing actions and aligning them to other processes can be benefitial. For example, if a redesign or an update of a Web application is expected, be sure to provide resources and expertise to support the implementation of an accessible solution.
- Demand Accessibility
- Demanding accessibility features in tools and accessibility expertise for staff increases the potential capacity for developing accessible solutions. For example, when acquiring a database application, ask the vendor about the accessibility features and consider the long-term impact on the Web site.
- Integrate Accessibility
- Integrating accessibility into the development responsibilities rather than as a separate activity enables the production of accessible content without too much additional work. For example, a Web master could have the new responsibility of checking the accessibility of the content before it is published.
- Validate Solutions
- It is often useful to validate accessibility solutions before investing time and effort implementing inadequate ones. This is especially useful during redesign phases of Web sites or in the early stages of content development. Involving users with disabilities is also valuable in the design phase.
- Make Use of Tools
- Be sure to get the best possible accessibility support from authoring tools and development environment. Additionally, Web accessibility evaluation and repair tools can help identify and reduce accessibility barriers. W3C/WAI maintains a list of Web accessibility evaluation tools.