W3C logoWeb Accessibility Initiative (WAI) logo

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

Improving the Accessibility of Your Web Site

Page Contents

Introduction

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 Web standards such as 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 external Web site, you probably want to fix that first. If you are legally required to meet a certain level of accessibility in your internal Web site ("intranet"), your target will be at least that level.

In some retrofitting situations, organizations define a multi-tiered target with different dates for different levels: For example, meet WCAG 1.0 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).

Evaluating to Identify the Issues

It is usually most efficient to first identify all of the accessibility barriers on your site. However, if you have a few serious accessibility barriers that are fairly easy to repair, it may be best to repair those right away before going further.

The goal of evaluation before retrofitting is to define the accessibility barriers on your site and gather information to plan an efficient retrofitting project. Rather than thoroughly evaluating every page on your site, you can focus your evaluation on representative areas in order to get more valuable information with less effort. For example, templates, style sheets, and any elements that are the same across pages, such as navigation bars and footers, only need to be evaluated once and can then be skipped on pages where they are repeated. The priorities listed in the Prioritizing by Area section below also apply to focusing evaluation.

Ensure that your evaluation covers each feature and functionality (for example, data tables, forms, scripts) from each developer or development group. Your evaluation can focus on specific points to help guide your retrofitting plan, such as determining if a particular accessibility barrier is widespread or isolated. For example, are all your data tables missing necessary markup, or just some? If only a few tables are missing markup, your retrofitting plan may need to add table accessibility to quality assurance (QA) processes rather than to training. However, if none of the tables are properly marked up, you may want to add that to your education plan. You might also find that tables from one development group are done properly, but from another development group have problems. This further clarifies where education is needed and not needed as part of your retrofitting project.

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

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, specific recommendations for repairing each barrier identified, and guidance on the knowledge and skills needed for the repairs.

Optimizing Your Retrofitting

Optimizing Knowledge and Skills

Depending on your project staff and the type of accessibility barriers on your site, you might need to acquire additional knowledge and skills in order to repair your site. At a minimum, those involved in Web development will need to understand how to fix the accessibility barriers on your site, as well as how to avoid introducing new barriers.

It is often best to combine educating existing staff with bringing in outside expertise, either hiring additional staff or engaging consultants. A qualified accessibility expert can save time and effort in the long run by providing:

In addition to accessibility expertise, you may need other Web development skills. The Combining Expertise to Evaluate Web Accessibility [update with final title & link] document lists skills needed to evaluate Web accessibility, which are similar to the skills needed for repair.

Optimizing Processes

Distributing tasks

Accessibility repairs can be distributed among different people based on their skills and other factors. For example, making link text clear requires some knowledge of the content and usually only minor skills with the authoring tool. Whereas repairing scripts that generate dynamic content requires programming skills. By distributing tasks effectively, you can get more barriers fixed faster with less effort.

Clarifying requirements

One of the causes of accessibility barriers is that those in Web development did not know that they should make the Web site accessible. To avoid this problem in your retrofitting project, ensure that everyone 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.

Validating solutions before implementing them

Retrofitting projects typically involve identifying a barrier, developing a solution to the barrier, and implementing that solution throughout the Web site. 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 throughout your site.

Optimizing Tools

Which authoring tools and evaluation tools you use and how they are configured can impact your retrofitting efforts, as explained below.

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 retrofitting efforts. The document Essential Components of Web Accessibility describes the role of authoring tools and the effect 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.

Prioritizing the Repairs

Most sites developed without consideration for accessibility and other Web standards have many accessibility barriers that need to be repaired. Prioritizing by barrier and by area, as explained below, makes the project more manageable and ensures that the more important repairs get done first.

Prioritizing by Barriers

One approach to retrofitting is to fix all of the Priority 1 barriers first, and then fix lower priority barriers later. There are several disadvantages to this approach: you have to go back over templates, style sheets, and pages multiple times; you will miss easy-to-do, lower priority items; and you can get hung up on a few hard problems, instead of getting lots of easy things done quickly.

A more effective approach in most cases is to do all of the high impact and easy repairs while you are working on a page, template, style sheet, etc. Then address harder problems later. This approach has several advantages: it usually takes less time overall, and you get lots of changes done quickly. This helps demonstrate your commitment to improving the accessibility of your Web site as soon as is feasible.

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

  1. Impact on people with disabilities. Accessibility barriers are often identified by WCAG 1.0 Checkpoint. Each Checkpoint has a Priority that helps determine the impact of a particular accessibility barrier. The actual impact on users of a specific barrier depends on the context of your site. For example, poor color contrast in the main content has high impact on some people with disabilities, whereas in generic footers it may have low impact.
    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 require a simple change to the template that is automatically propagated throughout the Web site, or could require changing every page manually. Repairing missing alternative text equivalents requires knowing the content and understanding how the text is used; whereas, changing a site to effectively use style sheets requires CSS skills.

Prioritizing by Area

Another aspect of prioritizing retrofitting is determining which areas to work on first. It is usually best to first 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:

After you have repaired the major accessibility barriers on your Web site, there are several things you can do to help avoid creating new barriers and to continue improving the accessibility of your site.