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:
- Getting started understanding the issues, and communicating your commitment to improve the accessibility of your site.
- Developing a retrofitting plan by identifying accessibility barriers and prioritizing repairs.
- 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.
Getting Started
Understanding the Basics
A first step in retrofitting your site is understanding the basics of Web accessibility.
- Introduction to Web Accessibility briefly introduces Web accessibility and links to additional resources.
- 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.
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:
- 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).
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:
- Conformance Evaluation of Web Sites for Accessibility describes an approach for determining if a Web site meets accessibility standards, including using evaluation tools and manually evaluating pages.
- Checklist of Checkpoints for WCAG 1.0 lists the WCAG checkpoints by priority level and topic. (For background, see the "What is in WCAG 1.0" section of the Web Content Accessibility Guidelines (WCAG) Overview document.)
- Combining Expertise to Evaluate Web Accessibility [update with final title & link] describes recommended expertise and considerations for effective collaboration to evaluate Web accessibility.
- See also Evaluation and Repair Tools below
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:
- 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.
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:
- 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
- Purchasing different tools with better accessibility support
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.
- Selecting Web Accessibility Evaluation Tools provides guidance on choosing tools based on parameters such as your development environment, and the tool functionality.
- Web Accessibility Evaluation Tools is a database of over 100 tools that can be searched by different tool features.
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:
- 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.
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:
- 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
Next: Strategic Planning
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.
- Developing Organizational Policies on Web Accessibility describes considerations when making simple or comprehensive policies for organizations.
- Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization helps determine what requirements apply to your organization.
- International Policies Relating to Web Accessibility links to information on government policies relating to Web accessibility in countries around the world.
- 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.