Accessibility issues/bugs should just be treated as other issues/bugs

[bruce-usab]

From @drewnielson (with permission):

I love the idea of identifying "critical" accessibility issues to help prioritize issues that really prevent users from performing core functions and/or obtaining vital information.

• Rather than creating a new construct or system for rating sites based on accessibility conformance, I would recommend considering guidance to include accessibility issues/bugs within already familiar methods for defining and categorizing issue severity
  • For example, in commonly accepted bug tracking practices the highest level of severity is typically reserved for issues that make an application or website unusable and/or untestable (essentially the same concept as your "critical" issues concept); it could simply be a matter of encouraging developers and testers that if functionality is not usable even for a subset of users with disabilities, it should still be considered unusable; other categories of reduced severity identify issues based on impact on the user's ability to perform site/system functions
• Incorporating accessibility issues into an already commonly-accepted approach for issue severity categorization could help developers better evaluate overall impact on users based on number of issues by level of severity; this also has important implications for release/production decisions and Service Level Agreements for bug fixes and remediation.

There is some pretty common coalescence on the same basic structure (in my own words):

• Severity 1 (aka Critical or Urgent) - the bug/issue renders the site/system/application inoperable, unusable, or untestable
• Severity 2 (aka Major or High) - the issue/bug prevents the ability to perform some core functionality, but there could be some workaround
• Severity 3 (aka Moderate or Medium) - the issue/bug affect some minor functionality, but there is no workaround
• Severity 4 (aka Minor or Low) - the issue/bug affects a minor functionality, and there is a workaround
• [Bonus Severity 5 (aka Cosmetic)] - the issue/bug does not affect functionality, but diminishes user experience in some way (e.g., misspellings, bad page spacing, poorly structured page content, etc.)

The actual details of severity numbering/labelling and category definitions aren't as important as the overall concept of severity classification. And what I am advocating is that we simply emphasize users with disabilities and accessibility issues as part of severity classification. If a bug affects functionality for users with disabilities (i.e., because of an accessibility issue), then that should fit within whatever severity classification a project/organization has in place, as long as we make that requirement clear.

Thanks again for the great work you're doing and for yesterday's presentation. I appreciate the opportunity to provide some input. Also would be happy to have additional conversation any time.

[jspellman]

Thank you @DrewNeilson for your thoughtful comments and suggestions. I am referring your comments to the group developing use cases for evaluating the conformance model. I will add a concern that was raised several years ago when we were evaluating different conformance models. We must be cautious not to build a hierarchy of severity that does not treat different disability groups fairly. What I like about your proposal is that it addresses severity only by getting the task done (not the guideline). I worry that most cognitive issues would end up in Severity 5, when cumulatively they are a Severity 1. It's a difficult problem from a standards conformance perspective. I welcome further thoughts you have and would be happy to discuss it with you. You can contact me through Bruce, who has my phone number, email, or Github comments.

[DrewNeilson]

Thank you @DrewNeilson for your thoughtful comments and suggestions.

You tagged the wrong person. You meant to tag @drewnielson. I'm not involved with this.

[sajkaj]

Thanks for this comment on behalf of the Silver Conformance Options group where we're discussing this comment. You can read our initial discussions here. While there's much to like in the approach you suggest, we're concerned about the cummulative effect of multiple issues, even when there are work arounds. Perhaps one, two, or three such are tolerable. But, what if there are a dozen or more? If you have any thoughts on this, we'd be happy to hear them. Thanks again!

[drewnielson]

Great, glad to hear you are having some good discussion. Yes, accumulation of multiple minor issues can still create an overwhelming burden for users. In my experience, decision-makers still build mechanisms to consider the effects of minor issues on users. In other words, they don't typically just give a pass to anything that is low severity. In some organizations, I have seen decision-makers set thresholds for an allowable number of issues in each severity category at particular milestones. For example, in early iterations of a product, while still exploring functionality and getting early feedback from beta users, it might be more tolerable to have minor issues hanging around, acknowledging that minor inconveniences and work-arounds are not desirable, but perhaps acceptable as core functionalities are perfected. As the product moves to full release, then even the minor inconveniences should be addressed. Admittedly, some approaches to addressing cumulative issues in low severity categories can be more subjective. With that said, if I am a product owner, and I start to see minor issues stack up in releases (including accessibility issues if they are counted among my issues list), I would start to question my development team's reasoning and task prioritization.

…

[chaals]

Framing accessibility problems this way, and pointing out clearly that this is easily translated to common methods for tracking issues in products by design seems very valuable.

[sajkaj]

So, it's good to hear this is well known industry practice. But, is there something more normative we might try to follow as a guide? Something more than just suggestions in a textbook in good practice? Our problem, of course, is to capture this in consensus normative guidance. Any suggestions on where to look for codification would be very much appreciated!

[chaals]

I don't think you can turn this into normative requirements.

I think the value is in stating very clearly that people can consider their accessibility problems to be solved in the same way as any other issue, and then let them decide exactly how that works.

The point of work on authoring tool guidelines was to get this sort of thing adopted - what you could usefully do is work with organisations who produce widely used bug/issue management software to provide informative guidance on how to seamlessly integrate with their systems.

Aside from Github (an obvious one, where you might suggest they offer default labels, since they offer a pages functionality) there are a number mentioned in a recent tweet you could consider.

[jspellman]

I think we could map the outcomes to severity levels (informative). We could use a test (informative) that compares a percentage of low severity bugs to the total number of bugs as a measurement. We could give other ways to measure accumulated low severity for organizations who do not use bug tracking.