W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

[DRAFT] Improving the Accessibility of Your Web Site

Page Contents

Note: This document is a draft and should not be referenced or quoted under any circumstances.
$Date: 2006/03/01 14:28:32 $ [changelog]


Most organizations already have a Web site, and most of those sites were developed without considering accessibility. Thus most Web sites today have accessibility barriers that make it difficult or impossible for some people with disabilities to use the site. Some sites have several significant barriers, others have only a few minor barriers. Sites developed to meet other Web standards (for example, XHTML and CSS) usually have fewer barriers.

While implementing accessibility on an existing Web site may seem overwhelming at first, there are different approaches to make the process more efficient and effective. This document provides guidance for fixing accessibility barriers in existing Web sites; in other words, repairing accessibility problems, or retrofitting a site to improve accessibility. It provides approaches and tips for:

Implementation Planning for Web Accessibility is a related document that provides additional relevant information. It is primarily for organizations just starting Web accessibility with a new site. Many of the issues addressed in that document apply to retrofitting an existing site as well.

Getting Started

Understanding the Basics

A first step in retrofitting your site is understanding the basics of Web accessibility.

To get a [rough idea] of the type and amount of accessibility barriers on your Web site, you can do some initial evaluation.

Setting the Target

Many organizations use WCAG as a target for accessibility. For example, an organization sets its target to meet WCAG 1.0 Priority 1 and Priority 2 checkpoints (also known as Level Double-A conformance).

The motivations and pressures for your retrofitting project will likely influence your target. For example, if customers told you about an accessibility barrier that prevents them from using your site, you probably want to fix that first. If you are legally required to meet a certain level of accessibility, your target will be at least that level.

In some retrofitting situations, organizations define a multi-tiered target with different dates. For example, meet Priority 1 Checkpoints in key Web pages within 2 months, and meet Priority 2 Checkpoints in all pages within 9 months.

Developing an accessibility policy is a good way to clarify and communicate your target. Developing and adopting policies can take a while. Retrofitting need not wait for an official policy. The Addressing Next Steps section below provides links to information on legal requirements and organizational policies.

Communicating the Status of Your Retrofitting Project

Once you have determined that there are accessibility barriers on your Web site that you are fixing, communicate that to your users, for example, through an accessibility statement. An accessibility statement can include:

Make links to the accessibility statement easy to find; for example, put it as the first link in your home page markup (code).

Identifying the Issues

If you have a few serious accessibility barriers that are fairly easy to fix, you might fix those right away before going further. However, it is usually most effective to first identify all of the accessibility barriers on your site and plan a coordinated effort to repair them based on several factors described in the next section. <--edit above, per 24 Feb EOWG telecon-->

The following resources help evaluate a Web site for accessibility barriers:

[include below since not up-to-date in Preliminary & Conformance? or not?] [time-saving tip] 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.]

Many organizations hire accessibility specialists to evaluate their Web site. Accessibility specialists can also provide guidance on retrofitting your site, including general recommendations on approach and priorities, as well as specific recommendations for repairing each barrier identified.

Prioritizing the Repairs

The evaluation could yield a long list of accessibility barriers, especially if the site was not initially designed to meet current Web standards. Prioritizing by barrier and by [coverage], as explained below, makes the project more manageable and ensures that the more mportant reapirs get done first.

Prioritizing by Barriers

To plan for retrofitting, consider two parameters for prioritizing which accessibility barriers to address first: impact and effort. For each accessibility barrier, determine:

  1. Impact on people with disabilities. WCAG 1.0 Priority Levels are useful to help determine the impact of a particular accessibility barrier; however, the actual impact of a specific barrier on users depends on how it is on your site. For example, main navigation in images without alternative text ("alt text")is a high priority, whereas a few decorative photos without alt text is low priority; poor colour contrast in the main content is high priority, whereas in generic footers it may be low priority; and form labels poorly marked up can be high or low priority depending on the complexity of the form.] Evaluating with users with disabilities also provides insight about the impact of accessibility barriers in your Web site.
  2. Effort required for repair. The time, cost, and skills to repair a barrier varies greatly based on parameters such as the type of repair and your development environment. [For example, repairing barriers in footers could reuiqre one change that is automatically propagated throughout your Web site, or could require changing every page.] [For example, captioning multimedia is an additional cost; and changing a site to effectively use style sheets requires CSS skills; and alt text takes little skill, yet can be time consuming if it is poorly implemented throughout your site.]

[When fixing accessibility problems, people often focus first on top priority problems, and plan to do lower priority problems later. This requires going back over pages, templates, and style sheets more than once. If you do this, you will likely miss some easy to do, lower priority items. It's usually more efficient to go ahead and do all changes when you are in a page, rather than having to edit pages multiple times.

[Approach 1, strictly priority first:

  1. Fix top priority problems in key pages, then in other pages
  2. Fix lower priority problems in key pages, then in other pages

[Another disadvantage of doing fixes just by priority is that you can get hung up on a few hard problems and missing getting lots of eacy things done quickly.

[Approach 2, priority and effort:

  1. Fix top priority and easy problems in key pages, then in other pages
  2. Fix lower priority and harder problems in redesign

[Another advantage to this second appraoch is that you get lots of changes done quickly. This helps demonstrate your committment to imprvoing the accessibility of your Web site as soon as is feasible.

Prioritizing by [Area | Coverage]

Another aspect of prioritizing retrofitting is determining which areas to work on first. It is usually best to first work on repair those areas that have the greatest impact on users' experience with your Web site. Depending on how your site is developed, you may be able to repair many barriers through:

[Certain pages may have higher priority, such as:]

[Optimizing for Retrofitting]

[intro - what you need to do now in order to get things done effectively]

[e]Determine the source of accessibility problems in your Web site in order to correct them now and avoid them in the future.

[Is the accessibility problem throughout your entire Web site, or just certain areas? Is the accessibility problem just a quality assurance (QA) issue (for example,just a few alt text equivalents are missing from images ("alt text"), or is is systemic (all image are missing alt text)?]

[What is the cause of the accessibility problem:

[Consider the following questions to help identify relevant sources of accessibility barriers on an existing Web site:

[Optimizing] Tools

Authoring Tools

Authoring tools are software or services used to create or modify Web sites, such as Web page editors and content management systems (CMS). Some authoring tools provide better accessibility support than others. Thus your authoring tool can help or hinder your accessibility efforts. The document Essential Components of Web Accessibility describes the role of authoring tools and the affect of insufficient support for accessibility.

You might be able to improve accessibility support in your authoring tool by:

The Selecting and Using Authoring Tools for Web Accessibility document includes questions to ask software vendors regarding accessibility support in current and upcoming versions.

Evaluation and Repair Tools

Web accessibility evaluation tools are software programs and online services that help determine if a Web site meets accessibility guidelines. There are also tools that help repair accessibility barriers. Some repair functions are built into evaluation tools, and some tools focus only on repair, such as HTML Tidy.

Some evaluation tools can be configured to be more useful to your specific project. For example, once you figure out which accessibility barriers you are going to address on which pages, you can configure the tool to only evaluate those barriers and pages. This speeds up the evaluation and simplifies the report.

[Optimizing] Processes

Distributing tasks

Accessibility repairs can be distributed among different people based on their skills and other factors. For example, adding alt text for images requires some knowledge of the content and minor skills with the authoring tool. Whereas repairing scripts that generate dynamic content requires programming skills. [Distributing tasks helps get repairs done faster and...]

[Validating solutions early | Improving evaluation throughout development]

Before you implement an accessibility solution, validate that it is effective. Involving users with disabilities and having accessibility specialists evaluate your planned repairs can catch any problems before they are [propagated | replicated] throughout your site.

[Clarifying Responsibilities]

Ensure that everyone involved in Web development knows that accessibility is a requirement (even if you do not yet have an official policy). Include accessibility in development guidelines, quality assurance processes, project sign-offs, etc.

[Optimizing] Skills

[Ensure that you have the necessary knowledge and skills to repair the accessibility barriers on your site. | Chances are you will need to acquire some knowledge in order to be able to repair the accessibility barriers on your site.] You might need to acquire additional skills through training existing staff, hiring additional staff, or engaging a consultant.

It is often best to combine [educating|training] in-house staff with bringing in outside expertise. A qualified accessibility expert can save time and effort in the long run by providing:

[Anyone developing content for your Web site will need to know some basic things about accessibility. Each individual involved in Web development needs to be aware of and have a basic understanding of Web accessibility.]

In addition to accessibility expertise, you may need [skills such as CSS and ?.]

In addition to repairing the most important accessibility barriers on your site right away, there are several things that you can do to continue improving your site's accessibility in the future.