Setting priorities for accessibility issues

I’ve had the privilege of working as a contractor on the Intuit Accessibility Team for several months now. Before my time at Intuit, I worked at eBay, where I put together a strategy for prioritizing accessibility issues. Today, I’ll share that strategy, making setting priorities easier and more consistent for you and your team.

Distinguishing general software issues from accessibility issues

If we’re looking at prioritizing accessibility issues, then we first want to look at the types of typical software issues you and your users will experience. They include the following:

• Bug: A problem with the software
• Feature: An improvement to the software
• Story: A user-focused translation of a software requirement
• Task: Some work that must be done
• Subtasks: A smaller unit of work associated with a task

Depending on the issue you’re dealing with, you have several prioritization considerations. How many users are affected? What is the monetary value or cost of not fixing a bug? Are critical/flows affected? How much effort is needed? Is there a legal/security/etc. requirement? And how much importance does upper management place on this issue?

Accessibility issues, then, are barriers that affect someone because of a disability. You can also call them a barrier created when a user’s accessibility needs are not met. Mandate 376 – Functional Performance Statements provides a list by the EU of accessibility needs, such as usage without vision, with limited vision, and without perception of color.

When prioritizing accessibility issues, instead of asking how many users are affected and how much it will cost, we must understand that these issues are for people with disabilities—a protected class. The other listed questions, however, still apply (e.g. are critical/flows affected, how much effort, upper management involvement), especially the legal requirement.

It’s common for accessibility to be a legal requirement. For example, companies that work for the federal government or for a nonprofit organization have legal accessibility requirements. This means they have to conform to WCAG Level AA, meeting all Level A and Level AA requirements without exception. Even missing one requirement means you’re not conforming. Most accessibility issues are failures to meet WCAG requirements, but the question is, should accessibility issues be high priority (P1 or P2)?

I would say that they should not be, with exceptions. For example, if there is a legal issue or user complaints, then they should definitely be prioritized. This does not mean every accessibility issue should be a P1 or P2 priority.

How to prioritize accessibility issues

Prior to my strategy, the Intuit Accessibility Team had suggested something like the following:

• P0: Very rarely used. For example, it completely blocks non-mouse users from completing the tax process. Legal ramifications.
• P1: Critical sections are not available to keyboard and/or assistive technology users. Business partner demands.
• P2: Core functionality is not working but the user has an alternative method.
• P3: Accessibility is broken for individual elements, information is incomplete or confusing.
• P4: Enhancements, good to delightful, content adjustments

My prioritization is similar, but I begin by considering the size of the barrier. This sets the initial priority (P1 – P4). Other factors can then modify the priority up or down or set the order within a priority level (for example, if there are a number of P2’s, then prioritize within that priority level accordingly).

Before I move on, let me clarify how to determine the size of the barrier. The highest barrier are things that interfere with users’ ability to use the product. In the WCAG, there are four non-interference requirements.

• Provide an audio control when there’s audio content
• No keyboard traps
• No flashing or strobing content
• Provide a way for users to stop or control animations

Audio or animations can distract us from what we’re trying to do. Keyboard traps make it so that we can’t use the keyboard on a page. And strobing content that could trigger a seizure.

The next highest barrier would be something that makes use impossible for the user, followed by issues that would make use impossible if not for a workaround. The final two barriers are those things that make the page or website tedious or annoying to use and those things that technically fail to meet the guidelines but don’t create a barrier to use.

Prioritization level examples

Here are specific examples of my prioritization levels.

P1: Interference/impossible to use

• Keyboard focus trapped (Users that rely on keyboard become trapped)
• Animations or other effects trigger nausea, vertigo, epileptic seizure, etc. (The user has been made ill or injured)
• Custom element does not work with keyboard—arrow keys, space bars, etc. (Users that rely on keyboard can’t complete the desired action)
• Accessible name (alt text, aria-label, etc.) missing from page element that needs one (Users without vision aren’t able to perceive this content)

 P2: Workaround available

• Keyboard focus softly trapped (ex. Can’t forward tab through an element)
• Workaround: Focus appears trapped, but the user can use a standard escape method, such as Esc or using Shift+Tab to navigate the keyboard (This is somewhat subjective to who is experiencing the issue.

• Focus indicator missing on a card; sighted keyboard users can’t see where they are
• Workaround: The surrounding cards have focus indicators; the user can deduce the tab stop without a focus indicator is on the middle card

• Accessible name (alt text, aria-label, etc.) missing from page element that needs one; users without vision aren’t able to perceive this content
• Workaround: The page has heading “Please sign in” before two text inputs and a button. First input is labelled “username,” the second input has no label, the button is labeled “login.”

P3: Tedious/annoying to use

• Skip to Main Content link missing or if it’s broken (Users that rely on keyboard must navigate through all of the header content on every page, negative user experience but still possible to use)
•  Custom component interaction is different from the standard (Users have to learn multiple interactions for what appears to be the same type of component; e.g. don’t use arrow keys but instead require shift up and down)
• An element with redundant labeling (Screen reader users need to listen to extra information, may have to tab back if they left before the second voicing)

P4: Non-Barriers

• The same ID attribute value on every element of a page (Technically fails guidelines, but if the ID is never referenced, it will never create a barrier; should be fixed and is generally bad practice, but low on priority)
• Over-engineered (non-standard) custom element that doesn’t meet the accessibility design patterns, but somehow functions as expected (The user’s experience is the same, so no barrier is created)

Why this different approach to prioritizing accessibility issues is necessary

I’ve received some criticism regarding my approach to prioritizing accessibility issues. For example, people have suggested my approach is different from how other issues are prioritized. This is true, but I believe accessibility issues should be prioritized differently. As I stated before, people with disabilities are a protected class, so accessibility issues can easily become legal issues. This generally equates to conformance with WCAG. And there is no concept of “partial conformance;” it’s an all-or-nothing thing. Treating accessibility issues strictly as legal issues or prioritizing based solely on WCAG levels would have some issues prioritized too high or too low.

A second criticism is that it’s confusing for non-accessibility experts to prioritize. The thing is, the strategy itself isn’t intended to help product teams prioritize issues themselves; it’s to provide transparency. Supplementary documentation with specific examples can solve this confusion, but this should be created by an accessibility team implementing a similar strategy.

And one more criticism is that the “tedious/annoying” things would be higher priority issues for people with some cognitive disabilities. It’s true that “if it doesn’t fail WCAG, it’s a usability issue” is one way people with cognitive impairments are failed by how some accessibility folks apply the guidelines. And if a task is made impossible because of a cognitive disability, it should be prioritized as such.

The prioritization strategy has gone through several iterations and has been reviewed by my team members at eBay and by third-party consultants. Representatives for user advocacy groups I’ve worked with have also approved of it.

Keep in mind, making your app accessible is a priority, but it’s unreasonable to have a team work only on accessibility issues. On the other hand, if the team isn’t building an inclusive experience, then they’ll have a lot of accessibility bugs and will feel like they’re always addressing them. My hope is that this strategy provides a rationale for how, why, and when to prioritize accessibility issues and how to do so consistently.

Ultimately, reducing the amount of work and debate that revolves around accessibility issues while helping those with disabilities is a win-win for everyone.