Re: Notes re a roadmap to reaching consensus

> They can’t do everything at once. Therefore, they cannot treat everything
as equally important. We need to acknowledge that and draw from the
experience of that process.


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.

> It won’t be 100% accurate, but we can draw on experience, typical usage,
and typical designs to inform a likely impact.


This however is the concern raised by Gregg: "typical usage" - as for many
disability needs, the user requirement is atypical for the individual user,
as Gregg notes when he wrote "*Even a submit button may be incidental if
the user cannot determine whether they should submit something or not*."

> if you are on an shopping site the context is buying things


Respectfully, that is a far too simplistic perspective.

Many 'shopping sites' are more than just pure-play product listings and
shopping cart functions. Often the site is a mix of marketing and sales: a
makeup company will sell their makeup online for sure, but will likely also
feature health and beauty "tips" via blog posts, social media activities
and other forms of "sticky content" (
https://www.clinique.ca/wedding-prep-beauty-guide). While revenue
generation may be the company's ultimate goal, the importance of the
"sticky content" to draw in potential customers may be an equally or at
times more important short-term business goal (i.e. if everyone sells the
same widget at the same price, what are other ways of differentiating a
site to give it a competitive advantage? Competition for "eyeballs" [sic]
is the retail industry's #1 consideration... you have to get them in the
"virtual door" before you can even contemplate making the sale.)

As Gregg wrote earlier: "... *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.*..."

I will suggest the reality is that *context is almost always personal*:
each individual will have their own reasons for navigating to and
'consuming' the screen content. A significant majority *MAY* have the same
or similar contextual reason (the 80/20 rule?), but as this thread touches
upon, we need to also acknowledge and address the 20% (atypical) needs as
well. So while context is indeed important, as an evaluation metric it is
hardly (IMHO) dependable, due to the bias Gregg (and to a certain extent
Shadi) previously noted.

JF

On Thu, Oct 6, 2022 at 7:21 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Gregg,
>
>
>
> One overall comment on the topic: People creating digital products *have
> to* deal with & work through these issues regardless of whether WCAG
> provides guidance on them.
>
>
>
> For example, prioritising accessibility fixes. They can’t do everything at
> once. Therefore, they cannot treat everything as equally important.
>
>
>
> We need to acknowledge that and draw from the experience of that process.
>
>
>
> On the comments:
>
>
>
> > This is where I have the problem.    Why is it assumed that a functional
> button is always more important than a content image.
>
>
>
> It won’t be 100% accurate, but we can draw on experience, typical usage,
> and typical designs to inform a likely impact.
>
>
>
> For example, WCAG 2 treats a duplicate ID on a component not visible to
> the user (or AT) at the same level as a missing accname on a button. In
> over 90% of cases (maybe 99.9%?) the accname will be more important, but
> WCAG 2 puts it at the same level.
>
>
>
> Would our more granular severity approach be 100% accurate? No, but based
> on how interfaces are typically put together we could apply more
> granularity than in WCAG 2.
>
>
>
>
>
> When you break down the requirements to a lower level that becomes more
> realistic. Not perfect, but potentially the basis for more a granular ruler.
>
>
>
> > Not sure I understand.  Lower level than what?
>
>
>
> A lower level than SCs. In the sub-group we were looking at the test level
> and applying severity there, rather than at the guideline or method level.
>
>
>
> If we take that approach, then we’d need to work through how the severity
> would be used to pass/fail at the guideline level.
>
>
>
> >  making the SC more technology specific DOES make them easier to to read
> and apply — to those technologies.   But it makes them less technology
> agnostic —which 1) makes them less useful for general guidelines like WCAG
> 2  and 2) makes them less future proof.   As new technologies come out -
> they aren’t covered.
>
>
>
> Note in WCAG 3 we’re talking about guidelines/outcomes/methods/tests.
>
>
> Those concerns have been discussed, an so far the guidelines & outcomes
> are tech agnostic and methods are tech specific (or general).
>
>
>
> So the tricky aspect of applying severity at the test level is whether
> that would need to be normative, and how you score (or otherwise use the
> severity) for passing guidelines.
>
>
>
>
>
> > It is just that when you start saying context - there are millions or
> billions of them.  Where do you start and end?    If you just use the ones
> you think of ?— what of all the ones you don’t?
>
>
>
> By context, I mean the context you can draw from the page/app/task, not
> the user’s context.
>
>
>
> For example, if you are on an shopping site the context is buying things,
> so there is inherent prioritisation that you can apply with that context
> that WCAG cannot predict. It is something that needs to be set by the
> person making an accessibility claim, potentially with guidance from WCAG
> or an associated doc.
>
>
>
>
>
> > Selecting pages can be gamed by an author for self assignment — but an
> external evaluator would not - so it would not be game-able in a way that
> would protect anyone.
>
>
>
> Good, then the same should apply for people going through a process of
> selecting tasks/processes.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
> --
>
>
>
> @alastc / www.nomensa.com
>


-- 
*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"