Re: Notes re a roadmap to reaching consensus

Hi Alastair,

>  We thought the best way was at the test level, and to focus on critical
issues


The thought process as discribed is understood. What is not clear is
*"critical"
to whom*?

There have been multiple strawman use-cases presented in this thread that
have not been accounted for, from the too high mirror affecting the person
who needs to re-attach a medical device, to a caption file with a lot of
numbers impacting users who deal with issues related to dyscalculia. While
the mirror example is highly theoretical and not really "web" or digital in
nature, the captions with numbers scenario is both legitimate and squarely
in the conversation.

With respect to the sub group, I keep coming back to what Gregg said, "*we
always judge what is important by what is important/critical to us - or to
our imaginations of what would be important/critical to others.  And that
has not worked out well in the past for all those that get left out.*"

  Can you please help me understand then how this inherent bias is being
overcome? It seems to my thinking that *any* issue could elevate to
'critical' to at least one group of users - or at least a sub-set of that
group.

> This process would be to combine the two in order to help prioritise (or
measure) the accessibility issues. We do this kind of assessment a lot

Yes, teams will always have to build out a punch list of *remediation items*
that will see "winners and losers" (issue 7 gets remediated before issue
14, because the team cannot fix both simultaneously), however that only
applies to *remediation*: in new development isn't the goal to avoid issues
in the first place? And from that perspective, it shouldn't matter on
severity level - it impacts *some users* so don't do whatever it is that is
generating the error condition in the first place.

What am I missing?

JF

On Thu, Oct 6, 2022 at 4:14 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> > But it is done in the context of business and target market, costs, and
> profits.
>
> >
>
> > Evaluating priority of features based on equity -  is much more complex
> — and - I think it may be gordian.
>
>
>
> I agree, I’m not suggesting that.
>
>
>
> Assume that we have a set of issues based on a WCAG 3 audit, they may be
> classified at a basic level within the guidelines (similar to A, AA, AAA).
>
>
>
> The organisation stakeholders have their feature / task priorities.
>
>
>
> This process would be to combine the two in order to help prioritise (or
> measure) the accessibility issues.
>
>
>
> We do this kind of assessment a lot, and I’m sure others do as well, it
> isn’t particularly difficult to do.
>
>
>
> The issue severity sub-group focused on whether and how you could include
> severity within the guidelines.  We thought the best way was at the test
> level, and to focus on critical issues (rather than categorising
> everything).
>
>
>
> We still have a bunch of questions to answer on that:
>
>
> https://raw.githack.com/w3c/silver/c4f15d75f75688e4b9b8ec45a4c7f7aad4829822/guidelines/index.html#critical-issues
>
>
>
> Which is what the new sub-group will pick up, as well as looking at the
> contextual version as well.
>
>
>
> -Alastair
>


-- 
*John Foliot* |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"