During my career, I’ve performed scores of audits and expert reviews to look at the accessibility of web-based systems (websites, web-based applications, intranets, etc.). Of those, I can count on one hand the number of systems tested that were pre-production. In nearly all cases, the testing was performed on systems that were already released to users. In such a scenario, an organization’s level of risk is at its highest, as people are using the system. Therefore the organization and its developers require sufficiently informative data output from the accessibility testing which is detailed, clear, and actionable. It doesn’t do the client any good to throw them a report filled with a bunch of accessibility violations unless that report also includes information to help them fix their problems. They need to know what their problems are, where their problems are, and how to fix them. There’s also an additional item they need to know: When to fix them.
Not All Accessibility Problems Are Created Equal
The Web Content Accessibility Guidelines structures its Success Criteria in terms of “Level”. Success Criterion can be Level A, Level AA, or Level AAA. Unfortunately, their explanation of the levels isn’t terribly clear. It was much more clear in WCAG 1.0, however the WCAG 1.0 Priority levels did not take into consideration any factors other than user impact. It is clear that in the early days of work toward WCAG 2.0, they understood that conformance level needs to take more things into consideration, as evidenced by this early draft. Unfortunately, the current WCAG documentation on Understanding Conformance currently lacks a description of any kind whatsoever on the topic of what the conformance levels mean and what differentiates each from the rest.
What is clear, despite the lack of guidance in WCAG, is that they acknowledge through the use of different levels that not all accessibility issues are created equal. Some items are more impacting on users than others. Some items are technically difficult or impossible to achieve. Some items don’t have good support among user agents or assistive technologies. As a consequence of all these factors and more, it would be rather reckless to treat everything as if they were all equal. In some cases, doing so could risk budgets while not helping the end user. Instead, remediation should be targeted to provide the best benefit quickly and cheaply.
Factors That Influence Priority
Prioritization is about one thing: utilizing the organization’s development resources in the most efficient manner toward the greatest possible good for both the organization that owns the website and the audience which uses the site. We must remember that the development staff has other responsibilities for the quality and security of the site as well as meeting the business’s needs for new features and capabilities. We need to ensure they’re able to remediate the system’s most important accessibility problems with minimal impact to their other responsibilities.
Impact on Users with Disabilities
Since the goal of any accessibility remediation effort is to make it more accessible, it makes sense to give priority to items that will have a high positive impact to the end user with disabilities. Conversely, it also makes sense to delay repair of things that will have a lower impact to the end user with disabilities. I recommend a scale of 1-3 for determining impact:
- High Impact. Users will be unable to perform important system tasks or unable to understand important content if this item is left not repaired.
- Medium Impact. Users will be able to perform important system task with some level of difficulty or will be able to understand important content with difficulty if this item is left not repaired.
- Low Impact. Users will be inconvenienced by leaving this item not repaired, but will be able to accomplish all tasks.
Ease & Speed of Repair
As before, if the goal of our remediation effort is to fix the system, it only makes sense to utilize our developers’ time wisely. Part of doing so is knocking out the easier things before the hard things. Easy things tend to take less time, which means we can get further down the road toward an accessible system by prioritizing the easy things over the hard. Doing so will give us the ability to get quick improvements with minimal effort.
Impact on Interface & Operation
There may be times when an accessibility-related repair may be necessary which would have a negative impact on the user interface and/ or operation of the interface as it is currently designed. One area where I see this happen very often is in color contrast of primary site templates. In these cases poor color contrast is used which is related to the organization’s branding as a whole. Improving the color contrast would essentially require a redesign of the site. In this scenario, things which will require significant redesign will need to be given much lower precedence over things which will have little-to-no impact on the interface.
Volume of Repeat Issues
What I often find when doing accessibility testing is that the same mistakes will be found over and over. Some of those mistakes will be repeated because they’re part of a template. Some of the mistakes will be repeated because common code is used throughout the site. For instance, forms may be created using a server-side library or class which is used to make all forms. In either case what happens is that the volume of similar issues will be quite high while the actual volume of offending code will be small. In this case, a large benefit can be realized quickly by fixing the templates or classes which cause the most common issues first.
Location of Issues
Accessibility issues that don’t impact anyone aren’t issues at all. One area where this is especially true is when it comes to the location of the issues. In any site, there will be those pages which get far more traffic than others. People commonly understand this concept as the 80/20 rule. In reality, it might be that 15% of your pages get 90% of your traffic. Whatever the case, you will want to remediate issues which occur on the pages with the highest traffic before those which don’t get much traffic at all.
Secondary Benefit
The Web Accessibility Initiative at the W3C has put together a series of resources they call Developing a Web Accessibility Business Case for Your Organization. Interspersed throughout that “Business Case” are assertions that accessibility has secondary benefits, i.e. improvements for older populations. It stands to reason then, that issues which provide numerous secondary benefits can be given higher priority during remediation.