Re: Notes re a roadmap to reaching consensus

Hi John,

The answers are in the presentation linked to earlier:
https://docs.google.com/presentation/d/1agb_XbMzroRtbscmDIMH1BxqZgDdWymqoxvLESN1LJA/edit#slide=id.g13832c96f03_1_15

And the minutes from TPAC are useful:
https://www.w3.org/2022/09/13-ag-minutes#t13

In short:
> 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?

In the sheet you’ll see that each functional need group is mapped to each test, so the answer is: anyone.

One of the things the sub-group agreed was that moving to a lower level of granularity for each item made it easier to assess criticality. It would be an aggregate thing, a bit like the current A/AA/AAA is an ‘on average’ categorisation, but with a bit more nuance.

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?

I don’t want to pre-empt the work (and I don’t think I have a good answer for that yet). The first step was to work out if categorising the tests by severity was feasible. We think so, so the next step will be look at how it could be scoped within a process, and how well critical issues can be defined. (I.e. are they always/usually/sometimes critical across situations?)


> 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?

In the primary work of the sub-group (the 1st proposal) it wouldn’t differentiate between instances, it would be a set as critical (or not) at the test level.

In the second (not explored yet) proposal, it would depend on scoping, but in principle you could set the features of the footer to not be critical. The way I have approached this before is more on a component/feature level within tasks. E.g. if the tasks in scope can be achieved without using the footer, and that is not the main way to achieve the tasks, any barriers in the footer wouldn’t be considered critical.



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

Agree, and I don’t think anyone has proposed ignoring any user-group / functional need group.
It would need to start on the basis that any barrier for key functionality is critical (or possibly a severity by test which is then multiplied by the importance of the functionality/content, but that would be v. complex).


> And what is a site's "context"? Who determines that? How? Will that be documented somewhere?

In this not-explored-yet proposal, I think it would need to be part of your conformance claim, so we’d provide (WCAG-EM like) guidance on what to scope in/out, and how to assess your features.

For the comments on levels (bronze-gold), I think we need to create the levels first and then pick the appropriate place to recommend organisations should get 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:

Ok, but the point was not to compare across groups, it was to demonstrate how something is a barrier.

If it is a barrier, and the functionality it is a barrier for is important, then that barrier is important. (And of course others can be in various scenarios, but this is a known, obviously important barrier.)


> With technology solutions such as Google Translate,

That’s missing the point, I was using that as an example of how you understand that the content is not understandable. If something is dense and jargon filled, that’s a known barrier for some folks with cognitive issues. Assume some users can’t understand that content, what is the impact on the site usage for them? I.e. being able to complete a task.


> isn't the goal to move towards a "shift-left" approach

In the industry in general, yes, I’d agree. However, in the context of WCAG and trying to make a good measuring ruler for accessibility, I don’t think that’s harmful. The same information for assessing impact post-testing can be used to prioritise / measure whilst you design.


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?

Any & all, I’m talking about an approach like: https://www.w3.org/TR/WCAG-EM/#step2e


> more contextual requirements that are critical for some, but of absolutely no importance to others.

This is mentioned a few times, but I don’t think (unless I’m missing something) it is relevant to proposals described.

If a requirement (e.g. focus-visibility), were to be marked as “critical” in WCAG 3, the current proposal is that it is treated as a critical issue. It doesn’t matter that it is not critical to other people, each instance of that issue is considered critical, and would need to be addressed to meet a certain level of conformance.


> 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.

The first step (which is what the sub-group has worked on), is whether it is feasible to agnostically measure the severity. I couldn’t make the 1st meeting of the new sub-group, but they will be working out the next steps.

Kind regards,

-Alastair