[ROUGH DRAFT] Developing Organizational Policies on Web Accessibility

Note: This document is a rough draft in development, and should not be referenced or quoted under any circumstances.
Current approved information is at www.w3.org/WAI/impl/pol
Last updated: $Date: 2008/11/24 20:38:04 $ [analysis & changelog]

Introduction

This page is part of a resource suite that recommends strategies and best practices for organizations planning to adopt Web Content Accessibility Guidelines (WCAG) or updating to WCAG 2.0 from WCAG 1.0.Whether your organization is adopting its first Web accessibility policy, considering updating from WCAG 1.0 to WCAG 2.0, or migrating to WCAG from other standards, this document addresses considerations that can arise when developing or revising your organization's policies on Web accessibility. The following sections address considerations in setting organizational policy in more detail by:

• Explaining how to identify legal and policy factors that apply to your organization
• Discussing considerations based on your organization type
• Introducing risks for non-compliance
• Describing how to conform to multiple standards
• Identifying steps to formulate and implement your Web accessibility policy, given the above considerations.

If you already have a Web accessibility policy, revisiting these topics is recommended, as the legal or social factors informing your policy may have changed since your policy was established.

Identifying Legal and Policy Factors that Apply to Your Organization

Because governmental policies exist that apply to some kinds of Web sites in some countries, organizations should ensure that their policies at least require the minimum accessibility mandated by any policies that already apply to their sites. Legal and policy factors apply differently to specific organizations and situations. For example, one organization might be required by explicit government regulations to make its Web sites accessible, while another organization follows the Web accessibility policies recommended by its trade association or required by a partner company.

To understand legal and policy implications for transitioning your Web content to WCAG version 2, you first must know what policies apply to your organization. For guidance, the following questions can help you identify how the legal and policy aspects of Web accessibility apply to the organization:

If the organization:

• Is required by law or other legal mandate to make its Web site accessible, or
• Provides Web content or software to clients who are required by law or other legal mandate to make their Web sites accessible

If so, then clarify whether the policy explicitly targets an existing Web accessbility standard or guideline, its version, and a level of conformance. For example, the Canadian Look and Feel Standards targets WCAG version 1, Priority 1 and 2, with an effective date of January 1, 2007.

• If conformance to U.S. Section 508 is required, meeting WCAG 2.0 Level A will achieve this goal.
• If conformance to WCAG version 1, Priority 1 and 2 is required, ask the administrative body to consider moving to WCAG version 2, Level AA as a meets-or-exceeds threshold

If you are uncertain whether your organization is subject to Web accessibility policies or legislation, see Determining Applicable Policies. Once you have confirmed the applicable policies, you should also question:

• Are the requirements adequate to meet the needs of people with disabilities?
  If the required guidelines might not adequately meet the needs of the Web site's users with some disabilities, the organization can include in its business case additional guidelines it chooses to meet. See Considerations Beyond Requirements.
• Are there specified guidelines, conformance levels, and dates for compliance?
  For example, does the policy state that a certain level of compliance is required by one date, and a higher level of compliance is required by a later date? See Considerations for the Future.
• Will policies later become applicable?
  For example, requirements might be in development now that will be enforced in the future; or, an organization might expand into countries or other markets where Web accessibility policies already apply. See Considerations for the Future.
• Does the organization understand the risks of failing to provide accessible Web sites?
  In some cases it is useful to include in a business case the negative impact on reputation and potential legal costs associated with defending against legal action for not complying with Web accessibility requirements. See Understanding Risks for Non-Compliance.
• Is the organization subject to multiple sets of guidelines or policies?
  If the organization operates is global, its Web content may be subject to multiple Web accessibility policies and standards. For strategies to meet this variety, see Addressing Multiple Standards.

Determining Applicable Policies

Web accessibility requirements can be in the form of policies, laws, regulations, standards, guidelines, directives, communications, orders, or other types of documents. Policies Relating to Web Accessibility lists governmental legislation and related information for many countries and regions.

Some governments have laws that specifically require that certain types of Web sites are accessible. Others might not directly specify Web accessibility, yet the Web is indirectly covered under broader anti-discrimination legislation, information and communications technology policy, or other laws or policies.

An organization might be required by non-governmental policies to make its Web site accessible, such as a university Web accessibility policy that requires department Web sites be accessible. Sometimes organizations are compelled to meet other policies, such as policies from trade or industry associations, professional associations, or standards organizations.

Considerations for Different Types of Organizations

• Government - Some governmental Web accessibility requirements apply only to national government ministries' or agencies' Web sites; some also apply to provincial or state governments. Some other levels of government, such as provincial or state, establish requirements independent of national requirements.
• Education - Many educational institutions and organizations are covered by governmental requirements for accessibility of Web-based educational resources and online learning environments. In some countries or regions, educational institutions are covered in broad policies along with other types of organizations; and in others there are policies specifically addressing educational institutions. In addition to governmental requirements, some educational institutions and organizations have established separate or more extensive requirements for accessibility. In some cases there is a specific policy on Web accessibility; in other cases Web accessibility is covered under broader accessibility policies.
• Industry and Non-Governmental Organizations (NGO) - Some government policies require industry and NGO Web sites to be accessible. These types of organizations might also choose to follow other Web accessibility policies, such as recommendations from trade (industry) associations or professional associations. Many corporations and NGOs establish their own policies for Web accessibility, which are often more extensive than those required by government policies. In some cases, policies established by corporations or NGOs might also apply to subsidiaries, vendors, and others who do business with the organization.

Considerations Beyond Requirements

Sometimes the required standards or minimum conformance level might not adequately meet the needs of the Web site's users with disabilities. If the needs of people with some disabilities are left out of the required accessibility standards, an organization might choose to meet additional guidelines in order to provide sufficient accessibility. Version 2 of the WCAG guidelines may cover a wider range of disabilities, and so conformance to version 2 may help the organization meet these users' needs.

Considerations for the Future

It is almost always significantly easier, more effective, and less expensive to incorporate accessibility early in Web site development or redesign, rather than retrofit existing sites later. Therefore, many organizations that might be subject to Web accessibility requirements in the future choose to incorporate Web accessibility as soon as feasible.

An organization might be subject to additional Web accessible requirements in the future because:

• Policies in development will apply to the organization
• The organization expands into countries or other markets where Web accessibility policies apply
• The organizations' customers may adopt Web accessibility policies, affecting their software procurements
• The organizations' existing customers may partner with or be acquired by organizations with corporate Web accessibility policies.

Some policies reference specific guidelines or standards for Web accessibility and include dates for compliance. For example, a policy might state that Web sites meet Web Content Accessibility Guidelines (WCAG) Level A by a certain date and WCAG Level AA checkpoints by a later date. However, an organization might determine that it is most efficient to address all the requirements at the same time.

Understanding Risks for Non-Compliance

Once the applicable policies are understood, your organization should understand the risks of non-compliance with those policies. For example, some organizations have faced legal action for not making their Web sites accessible. Not complying with accessibility requirements can result in significant legal costs and have negative impact on the organization's reputation. At times, the legal requirements for an organization might be unclear. In such cases, some organizations determine that it is in their best interest (financially and otherwise) to make their sites accessible, rather than risk legal action.

Addressing Multiple Standards

As described above, an organization may be subject to multiple Web accessibility policies; for example, standards from governments in different counties where they operate, from a trade association, and from a partner organization. Addressing different standards is more complex than addressing a single standard; however, because there is almost always significant overlap between standards, the work to meet two different standards is not twice the work to address one standard. In most cases an organization meeting the more comprehensive standard can easily ensure that other standards are also met.

For organizations that are concerned about meeting multiple standards, it can be effective to include in the business case detail on the overlap between standards. For example, an appendix that shows the similarities between the different standards can illustrate where it is not much more effort to meet multiple standards.

Fortunately for Web authors, version 2 of WCAG was developed simultaneously with other standards updates. When the Telecommunications and Electronic and Information Technology Advisory Committee (TEITAC) reviewed the original Section 508 guidelines, they did so with consideration of WCAG and other Web accessibility standards.  The committee’s membership included representatives from industry, disability groups, individuals contributing to the WCAG version 2 update and others working on European based Web standards. The effect of this effort has been to harmonize standards. With WCAG version 2, Level AA, adopters can be assured of meeting or nearly meeting myriad other Web accessibility standards.

Crafting Your Organization's Web Accessibility Policy

Organizational policies can be very simple, or very comprehensive. In either case, your policy should identify the standard and its version to which the organization commits to conform. For example, a simple policy might state:

[This organization] is committed to ensuring accessibility of its Web site for people with disabilities. All the pages on our Web site will conform to W3C/WAI's Web Content Accessibility Guidelines 2.0, Conformance Level Double A."

A more comprehensive policy might indicate:

• A timeline for compliance
• Scope of material to be modified and treatment of legacy content
• Plan for ensuring conformance to the standard and policy
• Restrictions on software or content providers

A sample comprehensive policy might state:

"[This organization] is committed to ensuring accessibility of its Web site for people with disabilities. New and updated Web content produced by our organization will conform to W3C/WAI's Web Content Accessibility Guidelines 2.0, Conformance Level A, by [date]. Existing Web content produced by our organization, and new, updated, and existing Web content provided for our site by third-party developers, will conform to Conformance Level Double A by [date]. We will initiate an internal monitoring program by [date]. Vendors supplying software used to develop our site will be required to provide information by [date] on conformance to W3C/WAI's Authoring Tool Accessibility Guidelines 2.0, Conformance Level A. Our home page and our 'about this site' page will include links to this policy. We will review this policy in the future to consider updating it to an advanced version of W3C's Web Content Accessibility Guidelines once available."

The following sections describe the steps to develop your Web accessibility policy in greater detail.

1. Reference guidelines clearly

The term "WAI Guidelines" is non-specific; it can refer to any one of the three accessibility guidelines produced by W3C/WAI. In addition, it can refer to either the current version (2.0) or the previous version (1.0). Provide a clear reference to the specific guidelines document and its version with which conformance is expected:

• "Web Content Accessibility Guidelines" (WCAG) explains how to make Web sites accessible.
• "Authoring Tool Accessibility Guidelines" (ATAG) explains how to make software better support the production of accessible Web content.
• "User Agent Accessibility Guidelines" (UAAG) explains how to make accessible browsers and multimedia players.

Version 2 of these guidelines are currently in varying states of completion. WCAG 2 will reach technical recommendation first; ATAG and UAAG are each currently in working draft stage. Organizations wishing to require conformance to WCAG 2.0 once that becomes a W3C Recommendation may specify conformance to the "Web Content Accessibility Guidelines" without specifying a version number.

2. Specify conformance level

• Specify an expected level of conformance for Web site(s). For example:
  • "Conformance to WCAG 2.0 Level A" sets the expectation that a Web site would fulfill all priority one checkpoints, which address absolute barriers to accessing content on a Web site.
  • "Conformance to WCAG 1.0 Double A" sets the expectation that a Web site would fulfill all priority one and priority two checkpoints, which address absolute and substantial barriers to accessing content on a Web site.
  • "Conformance to WCAG 1.0 Triple A" sets the expectation that a Web site would fulfill all priority one, two, and three checkpoints, which address absolute, substantial, and minor barriers to accessing content on a Web site.
• Specify an expected level of conformance for authoring tools used by the organization, or by third party developers, to produce content for the organization's Web site.
  • "Conformance to ATAG 1.0 Level A" sets the expectation that Web authoring software acquired by an organization can fulfill all priority one checkpoints for accessibility of the software user interface and support for production of accessible content. [See example under "#5 Set milestones" below.]
  • [To add to terms of subcontract]: "[Subcontracted Web developer] will consider the use of ATAG 1.0 conformant software where available. If not using ATAG 1.0 conformant authoring tools, [subcontracted Web developer] will ensure that all content and templates generated for [this organization's] production of content is WCAG 1.0 Double A -conformant, and contains no markup that will interfere with generation of WCAG 1.0-conformant content.
  • See "Selecting and Using Authoring Tools for Web Accessibility" for additional detail.

3. Define scope of Web site(s)

• Specify to what extent this organization's requirements should apply to new, updated, and existing Web pages. For example:
  • "This policy applies to all new, updated, and existing Web pages."
• Specify to what extent requirements should apply to Web pages provided by a third-party (subcontractor, or other information provider, but as part of main site). The Web site's users may need access to primary and to third-party content equally. It may take additional effort to educate and get compliance from third-party content developers. For example:
  • "This policy applies to all Web content produced or updated by [this organization]. In addition, [this organization] is taking the following steps to ensure accessibility of content provided by third-party developers [NOTE that for some sites, accessibility of third-party content may be essential to complying with government policy]:
    • Informing third-party developers of [this organization's] policy on Web accessibility;
    • Providing links to information and resources on implementing Web accessibility;
    • Providing the following incentives to providers of WCAG 2.0 Level AA conformant content...;
    • Monitoring and providing feedback on inaccessible third-party content;
    • Seeking alternative third-party content providers where original providers continue to provide non-conformant content.

  See Statement of partial compliance - third party content for guidance.

4. Set milestones for conformance

• Set a date by which the organizations Web site(s) will meet a given conformance level. For example:
  • "By [date] [this organization's] Web sites will meet WCAG 1.0 Double A Conformance Level."
• In some cases it may be practical to phase in accessibility by addressing all of priority one checkpoints rapidly, since these can be absolute barriers if unaddressed; then phasing in priority two checkpoints with the next round of site improvements [no later than a specified date]; with priority three checkpoints left as optional. For example:
  • "By [first date] [this organization's] Web sites will meet WCAG 1.0 Level A Conformance Level; and by [second date] [this organization's] Web sites will meet WCAG 1.0 Double A Conformance Level."
• Consider how to address questions of priorities that may arise especially for Web sites with a large number of pages. Do not make assumptions about which areas of a Web site or which Web services people with disabilities are interested in or not. For example:
  • "This policy applies to all areas of this organization's internal and external Web sites, including legacy content."
  • Or, "This policy applies to all areas of this organization's internal and external Web sites, with priority to [specify which areas] areas of the site; however, all areas of the site are expected to conform to [specify conformance level] by [second date].
• Consider setting date(s) for accessibility support in software. For example: 
  • "By [first date], all vendors of authoring tools used by [this company] should provide information regarding their plans for ATAG 1.0 conformance in future versions of their software. By [second date] [this company] will preferentially purchase ATAG 1.0-conformant authoring tools."
• Consider setting dates for browser and multimedia conformance, without restricting people's ability to use adaptive browsers.
  • "By [date], all vendors of browsers and multimedia players used by [this company] should provide information regarding their plans for UAAG 1.0 conformance in future versions of their software. By [second date] [this company] will preferentially purchase UAAG 1.0-conformant browsers and multimedia players.
    
• Consider setting dates for establishing internal resources for training, technical assistance, monitoring, and/or an internal Web page with links to such resources.

5. Define monitoring, conformance claims, and follow-up process

• Specify a recommended process and schedule for reviewing the organization's Web site for accessibility. For example:
  • "Each department will review all areas of the organizations' Web site under its control using the process described at Evaluating Web Sites for Accessibility, and will review all new material that it publishes by using the same process."
  • Each section of the Web site will include links for feedback on the site; this information will be compiled and considered during the review process."
• Specify whether or not conformant pages, or sections of a Web site, should be labeled as such. For example:
  • "The introductory page for sections of the Web site that have been determined to be conformant according to [link] process should display the [WCAG 2.0 Double A logo] or bear the following statement ["this page conforms to..."]

  See Conformance claims for guidance.

• Consider specifying a periodic review of areas of the Web site by an internal department with the authority to follow up on non-conformant areas of the Web site. For example:
  • "[This organization] will conduct periodic reviews of the Web site and any department with non-conforming Web pages will be asked to correct the problem within two weeks. Further problems in accessibility of an area will result in [specify as appropriate]"
• If you already reference WCAG 1.0, specify a process and schedule for identifying needed updates to conform to WCAG 2.0. Web sites that meet WCAG 1.0 - Level 2 are already very close to meeting WCAG 2.0 - Level AA. To understand the differences, see Comparision of WCAG 1.0 Checkpoints to WCAG 2.0. For example:
  • "Over the next quarter, [this organization] will update the Web site to comply with WCAG 2.0."
• Provide a mechanism for site visitors to report accessibility issues they experience. Provide a means to capture the location where the issue occurred.

6. Provide for integration and updating of policy

• If the organization has or is developing an overall policy for Web sites, for instance establishing best practices for use of Web standards, support for a privacy policy, internationalization, use of metadata, usability, etc., incorporating accessibility in the overall policy can be efficient, rather than establishing accessibility as a stand-alone policy.
• Organizations currently referencing WCAG 1.0 should review their current policy and update it to WCAG 2.0. Communicating the similarity of version 1 and version 2 may make updating the policy easier within the organization.