As discussed in last week’s blog post, “Accessibility Conformance Levels: Standards,” Level Access recommends a 98% conformance goal with technical standards. While achieving that goal for the launch of a new site is possible for some organizations, for others it is not an option. The level of conformance an organization launches with is often dependent on the level of risk an organization is willing to take, and many organizations often launch a site without a full level of conformance..
There is a risk that a user with disabilities will be unable to use your website, or another party may discover your website is not accessible. There are also individuals and law firms that will troll sites by running automated tools on those sites, and a site with automatically-detected violations can be a target. One way to reduce risk is to address automatic violations. Since the main point of accessibility is to remove barriers to access by people with disabilities, the priority focus needs to be making sure the core tasks of the site are accessible to people with disabilities. Use cases should be created and tested by users with disabilities who use assistive technology, accessibility features, and other techniques, and the user must be able to complete all core tasks of the site.
If you find yourself needing to prioritize, follow these steps:
- Address all non-advisory automatic violations for the core pages of site
- Address high-severity, non-automatic tested issues for core pages of site
- Support at some level all success criteria of WCAG 2.0 Level A and AA, even if the support level is not fully supporting the success criteria
- All core use-case tasks pass (can be completed) with a score of 3 (out of 5) or above (minor accessibility issues).
- Define a continuous improvement process to address the other severity defects as appropriate
These first steps don’t make an organization risk-free, but they should reduce risk considerably. Another way to reduce risk is to address non-technical issues such as how accessibility is communicated and addressed, as well as how requests and accessibility issues are handled within the organization.
Easy “milestones” toward WCAG conformance would be 90%+, 95%+ and then 98%+. Having an initial tier of functional use cases at a passing score of three and above would correlate well with a 90% maturity level of the technical side.
Some other considerations:
- Accessibility Statement. Organizations should create and post an accessibility support statement, not claiming or disclaiming conformance, but simply affirming their commitment and goals. Making a public commitment to accessibility can be an important step in recognizing the issues and communicating to others that you are aware of the need.
- Accessibility Resolution Policy. Create and verify a working accessibility resolution policy/feedback mechanism that is clearly posted. When users with disabilities run into an issue, many are likely to look for a way to communicate these concerns, or contact customer service representatives. Having a clear policy to take feedback and act on legitimate issues and work towards alternative interim solutions is key to lowering risk.
- Follow Applicable Regulations. In some regions, there may be specific requirements that must be met. For example, the Accessibility for Ontarians with Disabilities Act (AODA) requires conformance with WCAG 2.0 at different levels and requires accessibility plans and documentation.
- A Note About Settlements. Finally, if your organization has settled with an organization or the government, you need to adhere to the terms of that agreement: not doing so increases your level of risk. Based on the agreement’s terms, it may not protect you from additional risk from others seeking to access your web site. If you settle privately with one party on an accessibility issue, your organization may not ultimately reduce your overall risk because others with disabilities may still be able to litigate the same issue.
Web sites should ideally be launched with full conformance. When full conformance is not possible, organizations should ensure that core functionality is barrier-free and functional use cases pass. Automatic tests for core pages should pass without error, and all high- and medium-severity issues that pose a barrier must be addressed. Furthermore, you should have a process in place to communicate a commitment to accessibility, as well as an accessibility feedback process is in place. While these steps do not indicate full conformance, they reduce the risk to an organization and ensure that barriers to access are removed for people with disabilities.
This post is not legal advice and if you have legal questions about your level of compliance for accessibility please seek legal counsel.