Re: Notes re a roadmap to reaching consensus

Comments in-line:

You pass/fail each test, the results of those tests score towards the
> guideline. The severity would be used to say that some are critical (or
> not),
>

Critical to whom? Visible tab focus is critical to keyboard-only users with
sight, but essentially a non-issue to non-sighted users. What is the
criticality of missing visible tab focus?


> and that would be used for conformance and/or for prioritisation (TBC).
>

Recognizing that there is still work happening, can you elaborate on the
broad strokes of this please? Given that different failures will
impact different users, well, differently, how will this impact
prioritization?

As far as conformance is concerned, can you elaborate on that as well? If
visible tab focus is present, but it is at a 1.8:1 color contrast ratio, is
it conformant or not? Why or why not? (If your response is that it is
"partially" conformant, how is that "partial conformance" scored? What is
the severity of that scenario? Why?)


> Context based on the site or user isn’t applicable here, except that the
> AG group (process TBC) would have set a general level for each test within
> the methods & guidelines.
>

Continuing with visible tab focus, imagine a scenario where there is a link
in the footer region to persistent help
<https://www.w3.org/TR/coga-usable/#objective-7-provide-help-and-support>
(identified
as an important requirement for COGA). However, the visible tab focus for
all links in the web site footer (and just the footer) have been removed by
the author. Is the lack of visible tab focus on *THAT* specific link
more/less/equal in severity to all the other links in the footer? Why or
why not?


> This hasn’t been explored by the sub-group yet, but for me it is a
> combination of the site’s context + the accessibility barrier.
>

*AND* the user need (which maps back to the accessibility barrier). Once
again, non-visible tab focus is NOT a barrier to daily screen reader users.

And what is a site's "context"? Who determines that? How? Will that be
documented somewhere? (Not the "how it was determined" part, although that
will be important as well, but by document I mean formally documenting the
context of the site: "This site is about owning and buying Tamagotchis", so
that 3rd party evaluations know the intended context up front.)


> ...this would be another step afterwards (e.g. to get up a level to silver
> or gold).
>

I have heard this line of reasoning before and have another concern: it
very much sounds like some people are working under the assumption that
Bronze = WCAG A & AA today, and that Silver and Gold would be *more* than
that.

Given that likely no site today can honestly claim full WCAG conformance
(not even the W3C), I worry that the "new" things being brought into WCAG 3
would be viewed as similar to AAA Success Criteria today, and maybe even
AAAA (which doesn't exist, but...).

These new requirements and "tests" also seem to be being discussed as
'additive' to a conformance score, rather than subtractive (i.e. presuming
every site's starting point is Gold, and you 'lose' score points for not
fully meeting a requirement, as opposed to 'gaining' extra score points by
meeting new requirements, such as addressing many of the needs in Making
Content Accessible...COGA <https://www.w3.org/TR/coga-usable/> today.)

Given the reality on the ground today, do we really think that content
creators will "stretch" beyond minimum conformance requirements? (Some
might, for sure, but I wager the majority won't, and we've got close to 20
years worth of insight there already to back that up). If "legal"
conformance is mapped to "Bronze" (aka WCAG 2.x A & AA), and you only get
score points for those COGA needs at "Silver" that simply could not get
added to the 2.x standard, what incentive is there to start using those new
requirements going forward? If Bronze is "good enough", then Bronze is what
you will get more often than not.


> For example, if an identified barrier (based on WCAG 2 style testing) is a
> missing button name, imagine the button is invisible, how does that impact
> the task/page/view?
>

"Imagining" things as part of a user scenario is a useful exercise when
planning for development, but is highly inefficient when testing... I can
imagine all kinds of non-relevant imagined scenarios (or extensions to
scenarios) when I try to.

In the real world however, the button is either visible or not visible
(impacts sighted users), and has either an accessible name or doesn't have
an accessible name (for users dependent on Role, State, and Value
semantics). To me, that builds out four possible scenarios:

   - *Visible* button *with *an Accessible Name
   - *Visible*  button *without* an Accessible Name
   - *Non-Visible* button *with* an Accessible Name
   - *Non-Visible* button *without* an Accessible Name

In that context, we can all likely agree that the first scenario is our
goal (i.e. "passes") and clearly the last scenario is a complete failure,
but are the other two scenarios equal in severity? Why or why not?
(And then there is the rarer but not uncommon instance of when content is
provided exclusively for screen reader users? We've all seen class
attributes with values similar to ".SR_content"... how do you measure
severity issues on that type of content?)

And, returning to my first use-case, if one of those "buttons" is to
persistent help, does that further impact your severity? How? When? In what
manner?

If there is a visible page structure but no landmarks, how would removing
> the page structure affect usage?
>

To me personally? *In absolutely no way*, and I've been using websites
without landmark regions since long before the concept of landmark regions
(via ARIA or HTML5) became a thing (as, I will presume, many of the other
readers here have as well).

Here's a puzzle for those so inclined: is a modal dialog also an <aside>?
Would you pass or fail a modal marked-up as an <aside>? Why or why not? (If
you really want to take a crack at that, please start a different thread
:-) )


>  If the language is dense and jargon filled, assume you can’t read it
> (e.g. translate to Greek, if you don’t read Greek), how does that impact
> the site usage?
>

That too is a contextual question. For me, it depends on how critical the
information is on that page. With technology solutions such as Google
Translate, and browsers now integrating page/content translation right into
the browser chrome <https://vivaldi.com/features/translate/> (a feature I
frequently use in my browser of choice - Vivaldi), if all I need is a broad
understanding of the page (based on my Grade 12+ reading level) then quite
often those translation tools are sufficient - *for me*.

That may not be the same for users with a lower reading level, or who have
other cognitive issues at play. And the content itself (editorial) will
have an impact on severity: if the content is about critical medical
information, that is one thing; if it is about how to reset a Tamagotchi
(?) - meh... fun and potentially interesting, but hardly "mission critical"
(at least not to me *at this time*... but context is everything!)


>  This is a process we (working with product teams) and many accessibility
> companies conduct after an audit.
>

I appreciate this perspective from a post-audit point of view, but isn't
the goal to move towards a "shift-left" approach - where audits/tests
confirm that *barriers do not exist*, rather than seeking to find the 3764
different issues on "AcmeWidgets.com"? Perspective (like context) is an
important part of looking at this.


> I generally assume someone with a disability has just the same tasks &
> goals as the site’s assumed audience, and add any disability specific
> things (e.g. finding videos with audio descriptions).
>

A disability? Which one?

This also starts to drill into the actual issue: "you" assume.

Alastair, as an experienced practitioner of the craft, one whom I've known
for a number of years now, I would generally trust that your assumptions
would be fairly well grounded and accurate (based on the broader concept of
FOAF <https://en.wikipedia.org/wiki/FOAF>). But I would also remember
Gregg's important comment: "*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.*"

The process you describe is highly dependent on subject matter expertise -
which has been called out <https://github.com/w3c/silver/issues/463>
multiple
<https://lists.w3.org/Archives/Public/public-agwg-comments/2021Mar/att-0005/IBM_comments_on_the_WCAG_3_FPWD_-March_2.pdf>
times <https://github.com/w3c/silver/issues/400> as a significant barrier
in adoption <https://github.com/w3c/silver/issues/509>. More specifically,
industry commenters have already warned against subjective determinations,
for this very reason.


>  Currently we do that for prioritisation purposes as WCAG 2 is pass/fail
> only. That is useful, although we may not all agree it should be part of
> the standard. (There are other things we can do to support that usage.)
>

It's generally useful for a remediation project, less so for "new"
development, where planning trumps testing (or more accurately, testing is
used to confirm successful implementation, and not for surfacing existing
issues)


>  However, in future I think some requirements (e.g. spoons issues) need
> to incorporate the context of the site in order to make sense. I.e. we can
> cover more user-needs if we can include this type of process for
> conformance, particularly COGA related needs.
>

Indeed. The "spoons" issue is directly aligned with context, perspective
and individual user needs.

I've referenced the need for visible tab-focus in this thread as either
being critical or not-critical depending on the individual user-need, but
it is even more nuanced than that (as AG has also fine-tuned this
requirement twice more now: first by addressing color contrast of non-text
content <https://www.w3.org/TR/WCAG22/#focus-appearance>, and then on the
width and 'partially hidden' focus
<https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum> issues of
visible tab focus as well) - more contextual requirements that are critical
for some, but of absolutely no importance to others.

You pass/fail each test, *the results of those tests score towards the
> guideline*
>

Scoring! I have suggested for quite some time now that scoring is and will
be the critical task for WCAG 3. How a sub-team can look at Severity
without also directly talking about the score remains a mystery to me, and
I personally cannot understand how the Working Group can do that without a
scoring scheme already in place.

CONTEXTUALLY I'll suggest that broadly speaking it won't be pass/fail (it
rarely is, and that is the #1 issue with WCAG 2.x today), but rather
content that partially passes (or partially fails), of which severity plays
a key role there. The *ability to (agnostically) measure the severity (or
impact) of partial conformance* is the key to the entire discussion IMHO,
and that measure IS the score.

JF



*From: *Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
> *Date: *Tuesday, 11 October 2022 at 23:58
> *To: *Alastair Campbell <acampbell@nomensa.com>
> *Cc: *Sailesh Panchang <sailesh.panchang@deque.com>, w3c-waI-gl@w3. org <
> w3c-wai-gl@w3.org>
> *Subject: *Re: Notes re a roadmap to reaching consensus
>
> Contexts are important but I don’t know how we can judge them
>
>
>
> The question I have here is
>
>
>
>    - If I am an author and want to pass a WCAG requirement,
>
>
>    - and passing or failing depends on a context to be determined by a
>       tester,
>
>
>    - how will I ever know if I pass or fail?
>
>
>    - What tester?
>       - What will they decide the context is?
>       - Is there a master list of contexts that lists every one - so I
>       can look mine up to see how it will be tested?
>
>
>
>    - Is the context of this requirement the same for all users?
>
>
>    -  e.g. if a user is blind, and cannot see somethings on the page,
>       does it change the context / importance of others?
>       -  If so do I use that context?
>       -  Or all contexts for all people with disabilities?
>
>
>
> Might be just my problems but I can’t quite wrap my mind around it.
>
>
>
> Can you give me / us more to help understand exactly?
>
>
>
> Thanks
>
>
>
>
>
>
>
> On Oct 11, 2022, at 5:16 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>
>
> Hi Sailesh,
>
>
>
> > “So context is addressed via non-normative techniques”
>
>
>
> I think that maybe context is too wide a word in this topic. What I had
> meant by context was: What is the impact on the user’s task if there is a
> particular accessibility barrier in the way?
>
>
>
> That leads onto your second point:
>
>
>
> > “Often there are images (and sometimes CSS ones) with promotional
> messages or instructional text  that are not available to vision impaired
> users without suitable alternative text.”
>
>
>
> In the first proposal from the issue-severity sub-group the
> severity/impact was assessed at the test-level (under the guideline /
> outcome level), and it would have to be an aggregate, high-level view of
> the severity. That approach does have the problem you describe, it cannot
> account for the meaning of that content in context.
>
>
>
> The second proposal (less explored but had good support at the TPAC
> meeting) was to evaluate each barrier in context. For example, if the
> promotional message (not conveyed by alt-text) was missing for all users,
> what would the impact be?
>
>
>
> As David said: “ It might be easier for stakeholders closer to the content
> to provide priorities then for us (WCAG) to provide them”.
>
>
>
> Personally, I think it needs to be a combination, each method/test should
> provide guidance for its potential impact, and then a manual review
> provides your metric / prioritisation. That also aligns with current
> practices. How much is baked into the standard is then the question.
>
>
>
> These are things to be explored in the issue-severity sub-group, which
> will then report back to the full AG group.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
>
>
>
>
> *From: *Sailesh Panchang <sailesh.panchang@deque.com>
> *Date: *Tuesday, 11 October 2022 at 02:45
> *To: *w3c-wai-gl@w3.org <w3c-wai-gl@w3.org>
> *Subject: *Re: Notes re a roadmap to reaching consensus
>
> Couple of comments based on above exchanges:
> 1. About context: Techniques for WCAG are generally organized by the
> situation they apply to. In other cases, their description indicates
> when a particular technique is most appropriate.
> So context is addressed via non-normative techniques that can be
> accessed as technology / environment evolves without need to write /
> enhance SCs. This is in line with GV's  comments above.
> 2. GV writes: "This is where I have the problem.    Why is it assumed
> that a functional button is always more important than a content
> image".
> Indeed I said that to myself. Often there are images (and sometimes
> CSS ones) with promotional messages or instructional text  that are
> not available to vision impaired users without suitable alternative
> text.
> Thanks,
> Sailesh
>
>
>


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