Improving the Accessibility of Your Web Site

Page Contents

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:

Getting started understanding the issues, and communicating your
commitment to improve the accessibility of your site.

Repairing accessibility barriers on your site efficiently and
effectively.

Addressing next steps after initial retrofitting

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.

Understanding the Basics

Essential
Components of Web Accessibility shows how Web accessibility depends
on several components of Web development and interaction working together
and shows the relationship between the WAI guidelines: Web Content
Accessibility Guidelines (WCAG), Authoring Tool Accessibility Guidelines (ATAG), and User Agent
Accessibility Guidelines (UAAG).

How People with Disabilities Use the
Web describes how different disabilities affect Web use and
accessibility requirements for people with different kinds of
disabilities, and includes scenarios of people with disabilities using
the Web.

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

Preliminary
Review of Web Sites for Accessibility describes an approach to
quickly identify some potential accessibility barriers on a Web site.

Quick
Tips to Make Accessible Web Sites help identify potential
accessibility barriers to check for in a preliminary review, and gives
you an idea of the types of accessibility barriers that might need to be
fixed on your site.

Involving Users in Web
Accessibility Evaluation provides guidance on including people with
disabilities ("users") in accessibility evaluation throughout Web
development.
In addition to helping identify and prioritize accessibility barriers,
watching people struggle to use your site can be a powerful motivator for
your retrofitting project team.

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:

A brief description of the major accessibility barriers on your site,
so that users with disabilities know what to expect. 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.

A statement of your commitment to fix the accessibility barriers on
your Web site.

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

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.

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:

the latest best practices for accessibility solutions;

first-hand experience of how people with disabilities interact with the
Web.

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.

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:

Configuring your tools, for example, sometimes accessibility features
in authoring tools are disabled by default and need to be turned on

Using plug-ins or other add-on software to extend the accessibility
support of your tools

Upgrading your existing tools to the latest version, if they have
better accessibility support

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.

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:

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.

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.

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:

Templates that impact many pages

Style sheets that impact many pages

Elements that impact many pages, such as navigation bars and
scripts

Certain pages may have higher priority, such as:

The home page, which is often the first entry point to the site

The main pages and functionality based on the purpose of the site,
including

The path to get there from the common entry points

The path to complete transactions, such as ordering products

Frequently-used (high traffic) pages and functionality, including the
path to get there and complete transactions

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.

Integrate accessibility throughout your Web development. See Implementation Plan for
Web Accessibility. Ensure that when redesigns or updates are planned,
accessibility in included from the onset of the project. Accessibility is
much less costly and time-consuming when implemented from the beginning
of a project, rather than the end.

Ensure that you have an effective accessibility policy in place that
specifies that your Web site meet or exceed legal requirements.

Continue to evaluate accessibility in updated pages to ensure that new
barriers are not introduced. See the Ongoing
monitoring section of the Evaluation Approaches for Specific Contexts
document.

Document Information

Content last updated:16 March 2006
Editors: Shawn Lawton Henry, Shadi Abou-Zahra, and Education and Outreach
Working Group (EOWG) participants. Developed with support from WAI-TIES, a project of the European Commission IST Programme.