Re: Notes re a roadmap to reaching consensus

> Which (I will suggest) is also why traditionally issues related to "screen readers" are addressed before issues related to cognitive disorders. That too needs to be acknowledged and so far I have not read any proposal to address that imbalance.
The sub-group proposal was to map the critical issues against each functional need group. Whether we try to balance or score them is another issue, but at least it would be transparent.
What we can’t address on a per-test basis is things which build up with multiple instances (the “spoons” issue).
The rest is on the other approach to issue severity, around context.

> Many 'shopping sites' are more than just pure-play product listings and shopping cart functions…

Sure, but the importance of various features is evaluated by stakeholders all the time, it is part of the business and (if they do it) UX work. It can be done by value (to the business), overall usage, etc.

I’m not suggesting it is the context of the user, but the context of the issue within the features of the website.

I’m obviously not explaining this well, but a useful parallel is the sampling methodology in WCAG-EM:
https://www.w3.org/TR/WCAG-EM/#step2

So imagine:

  *   You are doing an additional post-test process to assess severity / priority.
  *   You are the site owner, or you are doing this in collaboration with them.
  *   You select the key tasks / processes that are the most used, or most important for the business.
  *   You also are required to select features or tasks directly related to disability, e.g. finding audio-described videos.
  *   You evaluate each issue in context, noting how severe an issue it would be for each task.
  *   You categorise each issues and use that to inform your backlog priority.

We go through this sort of process for a lot of our testing work as the first question when receiving audit results is usually “what are the most important ones to fix”.

As an external provider it isn’t always obvious what the key features are, but if you’re building the product you a generally very aware of that! So, it is best done as a collaborative process (or in-house if you have the expertise).

That is not a user-focused process, it isn’t a substitute for usability testing or other user-research. However, as a process it is feasible to do, and something that I think *could* be added at a silver/gold level.

It is something that will be further explored by the Issue Severity sub-group.

Kind regards,

-Alastair

--

@alastc / www.nomensa.com<http://www.nomensa.com>