This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.

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:

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 on 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.

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.

Back to Top

This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.