W3C logoWeb Accessibility initiative

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

Improving the Accessibility of Your Website

Page Contents

Introduction

Most organizations already have a website, and most of those sites were developed without considering accessibility. Thus most websites 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 website may seem overwhelming at first, there are approaches to make the process more efficient and effective. This document provides guidance for fixing accessibility barriers in existing websites; 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 website, 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 2.0 Level A and Level AA success criteria.

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 website, you probably want to fix that first. If you are legally required to meet a certain level of accessibility in your internal website ("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 2.0 Level A success criteria in key web pages within 2 months, and meet Level AA success criteria in all pages within 9 months.

Developing an accessibility policy is a good way to clarify and communicate your target. Note that developing and adopting policies can take a while, and 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 website 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). If some parts of your site are inaccessible, provide alternative ways for users to get the information or interaction; for example, contact phone numbers and mailing addresses.

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 evaluating 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 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 areas 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.

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, if only a few of your data tables are missing necessary markup, your retrofitting plan would include adding table markup to quality assurance (QA) processes. However, if none of the tables are properly marked up, you would add data table markup to your education plan. If tables from one development group are done properly but from another development group are not, this further clarifies where education is needed.

The following resources help evaluate a website for accessibility barriers:

Many organizations hire accessibility specialists to evaluate their website. 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

The following tips on knowledge and skills, processes, and tools help optimize retrofitting; that is, make it more efficient.

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 Using Combined Expertise to Evaluate Web Accessibility 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 website 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 website. 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 websites, 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 website 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 Level A barriers first, and then fix lower level 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 website 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 2.0 success criteria. Each success criteria has a Level (A, AA, AAA) 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 helps determine the impact of accessibility barriers in your website.
  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 website, 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 website. 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 website, there are several things you can do to help avoid creating new barriers and to continue improving the accessibility of your site.