This is an old draft. The published version of this document is at www.w3.org/WAI/bcase/.

WAI Resources

Creating a Business Plan
Business Case Samples
Implementation Plan Samples
Appendices

Sample Implementation Plans for Web Accessibility

This is an old draft. The published version of this document is at www.w3.org/WAI/bcase/.

Note: This document is an initial draft [see change log in progress] and should not be referenced or quoted under any circumstances. This document is under development by the Education and Outreach Working Group (EOWG), and will be offered to other W3C groups and the public for review.

Introduction

Regardless of what kind of organization, there will be some similarities in implementation considerations for Web accessibility, for example: Is there an organization-wide policy in place on Web accessibility? Is training available? Should there be some quality control to ensure that published Web pages meet the organizational standard for Web accessibility?

This page outlines some generic implementation considerations, and provides links [coming] to sample implementation plans addressing those considerations in different contexts, including corporate, government, non-governmental organization, educational institution, and Web-design businesses. Many variations of implementation plans are possible; these sample plans should in no way be taken as prescriptive.

[Note to EOWG writers: Please use this skeleton implementation plan as a template to add to or diverge from in preparing the context-specific implementation plans we have discussed.]

[Reference note: http://www.w3.org/WAI/EO/Drafts/claimcheck -- also http://www.w3.org/2001/Talks/0112-eEurope-jb/]

[Misc: institutionalizing a policy for new pages/sites, retrofitting pages/sites//capacity-building of internal expertise, external resources]

Implementation Considerations

Assess current situation

A first step may be assess the current situation within an organization with regard to Web accessibility. General answers to the questions below can often be obtained very quickly, and can provide sufficient information to shape priorities in an implementation plan.

Key questions include:

How much awareness is there already in the organization regarding the need for Web accessibility?
How accessible are the organization's current Web sites, including publicly visible sites as well as intranets?
What is the current level of expertise of individuals producing content for and designing Web sites in the organization, with regard to Web accessibility?
Do the authoring tools currently used in the organization support production of accessible Web sites?
Is there a centralized policy regarding Web technologies, style, and content used on the organization's Web sites?
Is the organization subject to external requirements regarding level of accessibility on its sites?

Develop an organization-wide policy on Web accessibility

An increasing number of organizations are developing organization-wide policies regarding their external and internal Web sites to ensure consistency and quality in design and function. Among other considerations, such policies can specify a given level of accessibility, and can do this by referencing W3C's Web Content Accessibility Guidelines, which have the advantage of being an internationally recognized W3C specification. [see also: benefits of using harmonized standard for Web accessibility]

Key considerations in setting such a policy include:

Naming the referenced document accurately, e.g. "Web Content Accessibility Guidelines 1.0" (WCAG 1.0) instead of "WAI guidelines" which is non-specific and could refer to other guidelines such as those for browsers or authoring tools.
Specifying a conformance level clearly, e.g. "Level Double A," which encompasses priority levels one and two checkpoints. If a conformance level is not specified, it may leave Web masters, their supervisors, and the public confused about what level of accessibility to expect.
Specifying a date by which such a conformance level should be achieved. In some cases organizations may want to implement accessibility requirements in stages, for instance by requiring "Level A" (priority one checkpoints only) as rapidly as possible, since lack of Level A conformance indicates absolute barriers to a Web site for some users, and then "Double A" within several months after that.
Specifying to what extent the requirements apply to new, updated, and old Web pages.
"Future-proofing" the referenced version number of WCAG, where possible. Web technologies evolve over time, and W3C is preparing an advanced set of Web Content Accessibility Guidelines which are also being reviewed carefully for ease-of-use; for organizations that have the flexibility to "upgrade" their document reference at whatever point in the future WCAG 2.0 becomes a W3C Recommendation, it may be advantageous to build in a way to do this.
Establishing a process for assessing conformance of Web pages, including consideration for consequences for non-conforming pages; and whether an accessibility logo should be used on conformant pages, and if so what are the policies for using it.

Promote awareness throughout the organization

Once a policy has been established, ensure that it is publicized throughout the organization.

Possible approaches include:

Using standard organizational channels to inform people of new policy.
Ensuring distribution of policy to all Web masters and those producing content for the Web, including administrative personnel.
Placing articles in organization's newsletter, to build awareness of the need for Web accessibility and the resources available.

Establish a recommended approach for self-evaluation, or organizational monitoring of sites

Web masters need some way to review their Web pages for accessibility, and to know how their sites may be monitored or evaluated within an organization.

Evaluation process

There are many different types of evaluation tools for Web accessibility; they each have different strengths and weaknesses. It is best to use several different types of tools and approaches in combination, for instance:

Bobby is an online or downloadable accessibility checker which provides a semi-automated assessment of accessibility problems on a Web page or group of Web pages. It can identify many problems on sites, and lists problems which it is not able to evaluate automatically and which require manual review.
The WAVE is an online accessibility assessment tool that flags any items on a Web page which should be examined for potential accessibility problems, and provides a description of what the problem might be.
Lynx-Me is an online text-browser-emulator. It generates a simulation of the output that someone using a text browser such as Lynx might encounter on a Web site.
The Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0. This list can be used manually to review the types of recurring problems on a Web site.
People with different disabilities as reviewers of sites. No automated tool at this point can pick up all the accessibility problems that might occur on Web pages; people who use different types of assistive technologies or adaptive strategies in reviewing sites may be able to identify additional problems.

Logo use

Once Web sites have been determined to be conformant to a given level of Web accessibility, an organization may or may not want to advise using a Web accessibility logo on conformant pages, or on the top page of a Web site. Before using a logo, note carefully the terms of use. For instance, the W3C logos for Web Content Accessibility Guidelines 1.0 indicate a self-declaration of conformance to a specific level of WCAG 1.0 (Level A, Double-A, or Triple-A), and must be linked back to information about the self-declaration statement and about WCAG 1.0 on the W3C Web site. Logos available from other organizations have different meanings and different terms of use.

How evaluation results are used

Consider contests, etc., or visibility of evaluation results, as motivators...@@ (for instance, a campaign)

Provide for training needs

Based on initial information about awareness of Web accessibility, and Web accessibility design skills, consider a range of training options which will enable Web masters in an organization to produce sites conformant with the organization's Web accessibility policy. One of the benefits of referencing the Web Content Accessibility Guidelines is the amount of training resources which have arisen around WCAG, and the amount of training resources currently in development by different organizations. [and benefit of providing feedback on common set of resources]

If initial awareness training is needed, see training resources and suggested curricula at....

If technical training is needed, see training resources and suggested curricula at... including resources available for online self-education including the "Curriculum for Web Content Accessibility Guidelines."

@@Monitoring

Periodic evaluation ?
How performed?
What resources allocated?
How publicized?
What follow-up on non-conformant sites?

@@Choice of authoring tools

Benefit of harmonized standard
Take advantage of authoring tools coming onto the market
Increase market demand for improved tools

@@Provide feedback through involvement with other organizations

Industry -- site design, authoring tool development
Disability community -- feedback on progress, importance of accessibility
Goverment -- etc
Research -- etc
W3C/WAI -- accelerate development of shared resources

@@Consider future policy framework

Re-examine Web accessibility policy in the future... other areas of site, distance learning, etc., media use, partnering, etc.

[@@Some Places to Start -- integrate info from this section]

Last updated 30 April 2001 by Judy Brewer (jbrewer@w3.org)

Copyright © 2001 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.