What is “Accessible Enough”?

This question often comes up when you (a product manager, project manager, or service owner) are in charge of a website/application or product with accessibility issues. You want to make your product more accessible, but wonder how best to do that with limited time and resources. Do you have to fix every single issue? How do you prioritize the work? In an ideal world, all accessibility issues would be resolved, and your product would be equally accessible for all users. But usually, this is not possible to achieve in the first round of assessment and fixes. 

What does "accessible" mean?

Stanford’s Accessibility of Electronic Content policy states that accessible is “When an individual with a disability is afforded the opportunity to acquire the same information, engage in the same interactions, and enjoy the same services as a person without a disability in an equally effective and equally integrated manner, with substantially equivalent ease of use.” The university’s standard for evaluating the accessibility of digital content is the Web Content Accessibility Guidelines 2.0, Level A and Level AA, which lays out a comprehensive set of technical guidelines to follow. However, technical guidelines do not always clearly emphasize the important goal of equal access and participation for users with disabilities. Early in the assessment and remediation process, you should not get so bogged down in minor technical violations that you forget to prioritize real-world ease of use for those accessing your product.

How to prioritize 

There are two main factors to consider when evaluating and remediating your product for accessibility.

1. The core use cases or user journey paths your visitors need to follow and complete
2. Critical and major blockers that people may encounter along those paths

When doing either automated accessibility testing yourself (by using a browser plugin or Siteimprove scanning) or when getting a more thorough manual review by one of our Digital Accessibility Consulting Engineers, the focus should first be on the product's most used and critical parts. Once you have identified and tested these components, use your results to get an overall picture of where the most significant problems lie. Automated testing tools rank the severity of issues they return. If you receive an audit from one of our Engineers, the issues will be ranked for their potential impact on users using the following scale: Critical, Major, Minor, and Trivial.

Issues ranked as “Critical,” and “Major” should be analyzed and prioritized for correction as soon as possible. Issues with these rankings are likely to create inescapable blockers for users, a significant need for workarounds, and require users to spend additional time completing tasks. This creates a situation where users cannot “acquire the same information” or “engage in the same interactions” in an “equally effective” manner to users without disabilities. Once the critical and major issues are resolved, the product will likely be much easier to use for various people, and your users will be less likely to require accommodations. In the short term, fixing “Critical” and “Major” issues can make the product “accessible enough” for a range of users, allowing them to complete tasks, hopefully without significant difficulty.

However, once the critical and major issues are resolved, you should not completely forget about the “Minor” and “Trivial” issues. These still should be addressed in subsequent development and release efforts. A significant collection of minor issues, if encountered in multiple places and multiple times, can frustrate users and slow them down significantly. Trivial issues are usually technical violations of good coding practices that, while not often perceivable by users, still add to long-term maintenance costs if they continue to pile up without correction. They may also repeatedly appear in automated test results, which detracts from your ability to highlight the good work you’ve done so far.

Commit to accessibility 

Accessibility must then become an ongoing commitment and part of your process. As products continually evolve and new features are rolled out, accessibility should be factored in at each stage, from requirements to development to testing. Once you have been through your first round of accessibility review and remediation, you will become much more confident in your knowledge and ability to prevent and quickly address any problems that crop up in the future. You no longer need to ask if the product is “accessible enough” to scrape by, but rather “are we doing all we can to make our product highly accessible to as many people as possible?”.