[DRAFT] Improving the Accessibility of Your Web Site
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:
- 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.
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 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:
- 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).
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:
- 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.)
- [Review Teams] provides guidance on...
- See also Evaluation and Repair Tools below
[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.
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:
- 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.
- 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:
- Fix top priority problems in key pages, then in other pages
- 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:
- Fix top priority and easy problems in key pages, then in other pages
- 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:
- 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 most important pages, and the path to get there from the common entry points [check shadi's version with wording on completing transactions]
- Frequently-used (high traffic) pages, and the path to get there [and complete transactions]
- Content that is particularly important for equal opportunity, such as job openings, [??, and legal information (such as terms and licenses)]
- Pages and functionality that might be particularly useful for people with disabilities, such as search, contact page, and site map
[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:
- Lack of an accessibility policy (that is, developers were not
to make the site accessible)?
- Lack of effective authoring tools?
- Lack of knowledge of the issues and solutions?
- Lack of skills to develop accessible solutions?
- Lack of sufficient evaluation and testing?
[Consider the following questions to help identify relevant sources of accessibility barriers on an existing Web site:
- Do the authoring and development tools support accessibility?
- Does an accessibility policy exist and is it being implemented?
- Do the developers have sufficient skills in Web accessibility?
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:
- Upgrading your existing tools to the latest version, if they have better accessibility support
- Purchasing different tools with better accessibility support
- Configuring - Sometimes accessibility features in authoring tools are not enabled by default, and need to be turned on. [Also, some things can be optimized for increased accessibility support on a specific Web site. For example, [???].] [Check your authoring tool help to figure it out.] [Ensure that your tool is configured for maximum 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.
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 paramteres such as your development environment, and the tool functionality.
- List of Web Accessibility Evaluation Tools includes over 50 tools, and can be searched by language, operating system, and many other 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.
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.
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.
[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:
- the latest best practices for accessibility solutions;
- first-hand experience of how people with disabilities interact with the Web.
[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.
- 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 you determine what requirements apply to your organization, including those from governments and other organizations in the form of laws, policies, regulations, standards, guidelines, directives, communications, orders, or other types of documents.
- International Policies Relating to Web Accessibility links to information on government policies relating to Web accessibility in countries around the world.
- Integrate accessibility throughout your Web development. See Implementation Plan for Web Accessibility. Ensure that when redesigns or updates are planned, acessibility in included from on onset of the project. Accessibility is much less costly and time-consuming when implemented from the beginning of a project, rather than the end.
- 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.
- Encourage tools to improve their accessibility support; for eample, authoring tools to meet ATAG and browsers to meet UAAG. See Essential Components of Web Accessibility.