Re: Notes re a roadmap to reaching consensus

Thanks 

This is helpful.

There are still lots of unanswered questions  — and I’m not sure how these will play out — if they will work.  But I can see where you are thinking / looking. 

I’ll hold on the other questions since most have to deal with the other techniques and approaches you say might play into this — and trying to explore them all in this thread would make it explode.

For now I will say that 

1) I have reservations on use of scoring or severity at the basic regulatory level.
 - and these reasons have to do with equity  -  where (almost) everything is severe for someone - and the fact that scoring always is game-able leaving people out at the judgment of the author (sometimes smaller numbers (tens or hundreds of thousands), sometimes more)

2) I think that there IS a place for them at higher levels beyond what is required to get extra points.  Companies are now doing that. 

3) I think assertions of process prototocols have a role that is testable but not outcome based.


All the best working on these ideas to see which work and which don’t.

My best suggestions though - are 
 if an approach has a fatal "con" - then we should focus on how to figure that one out - rather than back burnering it and exploring all the other aspects.
Be sure to test all ideas with a wide range of SC and not just the ones that are easy for the concept.  Maybe randomly sample SC + pick any that look troublesome  (rather than use the sweet ones)

All the best

G



> On Oct 12, 2022, at 1:31 AM, Alastair Campbell <acampbell@nomensa.com> wrote:
> 
> Hi Greg,
>  
> Remembering we have two proposals that have been discussed, there are two answers to each question:
>  
> Proposal 1, each test within each guideline is assigned a severity based on an aggregate assessment by WCAG. So:
>  
> > If I am an author and want to pass a WCAG requirement…
>  
> 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), and that would be used for conformance and/or for prioritisation (TBC).
>  
> > Is the context of this requirement the same for all users? 
>  
> 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.
>  
>  
> Proposal 2, after doing a WCAG evaluation and you have a set of issues, there is a process for assessing the severity of each instance of each issue. So:
> > If I am an author and want to pass a WCAG requirement…
>  
> You’ve already done that bit, this would be another step afterwards (e.g. to get up a level to silver or gold).
>  
>  
> > Is the context of this requirement the same for all users? 
>  
> 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.
>  
> 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?
>  
> If there is a visible page structure but no landmarks, how would removing the page structure affect usage?
>  
> 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?
>  
> This is a process we (working with product teams) and many accessibility companies conduct after an audit. 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).
>  
> 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.)
>  
> 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.
>  
> Kind regards,
>  
> -Alastair
>  
>  
>  
> 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 <mailto: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 <mailto:sailesh.panchang@deque.com>>
> Date: Tuesday, 11 October 2022 at 02:45
> To: w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> <w3c-wai-gl@w3.org <mailto: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
>