Developing Organizational Policies on Web Accessibility

Designing a policy

Your web accessibility policy may be standalone or integrated into other policies. The accessibility policy could be part of a non-discrimination or equal opportunity policy. Other related documents should also mention web accessibility. For example, brand guidelines, coding standards, and project management frameworks. This helps considering accessibility as a core feature, rather than an afterthought.

Your organizational policy may not be suitable for the public if it is an internal document. Consider providing a public accessibility statement that reflects your policy, goals, and achievements. This will communicate your efforts towards improving accessibility.

Reference standards

Reference specific standards in policy documents to ensure clear criteria for accessibility. The W3C Web Accessibility Initiative (WAI) provides a set of accessibility standards that are commonly recognized by governments and organizations from around the world. These include:

Web Content Accessibility Guidelines (WCAG) applies to all web content and applications. This includes content on mobile, television, and other delivery channels. The WCAG Overview provides more background.
Authoring Tool Accessibility Guidelines (ATAG) applies to websites that provide users the opportunity to generate content. For example, adding comments, posting to forums, or uploading images or videos. ATAG is also relevant if your organization provides tools, such as CMS’s, for staff or customers to manage websites and content. The ATAG Overview provides more background.
User Agent Accessibility Guidelines (UAAG) applies when additional plugins are provided to deliver additional content. Media players are a good example of this. UAAG also applies when custom controls are used to provide non-standard functionality. UAAG may also be relevant where mobile applications deliver web content as part of the application. It may also be relevant to the procurement process if your organization provides browsers for staff. The UAAG Overview provides more background.

Referencing Approaches

As technologies and standards continually evolve, it is important to keep policies current. The text of policies that include accessibility requirements tend to quickly become outdated. This introduces gaps between current accessibility standards and older policies. Ideally, a policy would reference the W3C/WAI standards. It should also define a mechanism to transition to newer versions of the standards when they become available.

Referencing Guidelines and Other Technical Specifications Explains options relating to referencing.

Define conformance levels

W3C WAI guidelines provide three levels of conformance: A, AA, and AAA. The generally accepted level of conformance in many countries is Level AA. It is critical for the success of your policy to select a conformance level you can realistically achieve. Once selected, specify what level of conformance is to be achieved for each referenced standard.

Examples

Define scope of policy

Clearly state the scope of your policy, and how it applies to different parts of the websites in scope. This includes third-party, legacy, and mobile content. It also applies to applications provided as part of these websites. Your policy may apply to websites internal to the organization, such as intranets, and to websites for external audiences. It also includes the tools used to create and to access your website.

Note that broader policies may impact your scope considerations. For example, public websites and services could be different from access to the workplace.

Examples

Set conformance milestones

For all items in scope of your policy, define clear and measureable milestones, including dates, by which each will be met. If the policy is already achieved, then say when the content was last reviewed. Deadlines should be realistic but issues should not be left too long.

In some cases, a phased approach might be appropriate. First, quickly fix significant accessibility barriers. Then implement fixes for other issues. You could do this as part of a planned maintenance update. Clearly outline any details of this type of approach in your policy.

Examples

Consider third-party content

Your accessibility policy needs to consider procured or syndicated third-party content. This is particularly relevant for third-party content that provides essential parts of a website. For example, this could include credit card payment services, video streaming channels, or online mapping services.

Site owners are responsible for ensuring accessibility or for providing accessible alternatives. This is true even if site owners don’t have full control over such content and services. For example, social media feeds may need to be monitored or moderated to ensure accessibility. See the WCAG 2.1 conformance requirement for complete processes and the concept of conforming alternate version for more background.

Examples

Define monitoring and review process

Regularly review progress towards policy goals. Update the policy when there are changes to the timescale or when you meet milestones

To maintain the target level of accessibility, specify a process and schedule to review content and tools in scope.

Feedback from users who might find accessibility barriers can help you identify issues. Your policy should include information on how you will gather feedback. It should also include information how how your organization will handle and respond to feedback.

Examples

Example policies

Comprehensive policies

More comprehensive policies may capture broader information. For example, how to implement the policy, or who or what departments are responsible, specific exclusions.

An example comprehensive policy is provided.

Policy template

In the template below, the [hints] in brackets are sections for you to complete.

Example Policy Template

[Organization name] is committed to ensuring accessibility of its website and intranet to people with disabilities. New and updated web content produced by our organization will meet [link to standard] [version number], [level of conformance], by [compliance date].

Existing web content produced by our organization will meet our standard by [existing content compliance date].

Content provided for our site by third-party developers will meet [third-party content standard] [version number] by [third-party content compliance date]. This [does/does not] include user-generated content.

We aim to ensure that our authoring tools and processes meet [authoring tools standard] [version number] by [authoring tools compliance date]. By [preferential purchasing date] we will preferentially purchase authoring tools that meet or exceed our web accessibility policy.

We will review this policy [review period] on or before the [policy review date]. This policy was last reviewed on [last review date], by [reviewer].

Next steps: Maintaining your policy

Keep your policy accurate and up to date. Regularly review your policy if it includes milestones. This is also true if it references particular standards by version number. Reviews should check that milestones have been met. It should also check if changes are required due to new or updated standards.

You may need to adjust your policy’s scope if you have new content. You may also need to adjust the scope if you make significant changes to the structure of your website. Changes in authoring tools or processes may also need to be thought about.

Longer term: Strategic planning

An accessibility policy is one part of a broader strategic approach to accessibility. Making accessibility an integral part of your web development strategy is more cost effective and efficient than considering it in isolation. You can do several things to help your organization create more accessible websites as standard.

Planning and Managing Web Accessibility outlines how to integrate accessibility throughout your web development. When you plan a redesign or updates, include accessibility from the start of the project. Accessibility is cheaper when tackled at the start of a project, rather than at the end. It will also take less time and resources to include accessibility from the get-go.