Re: Notes re a roadmap to reaching consensus

Thanks Alastair 

Comments below 

Gregg Vanderheiden
gregg@vanderheiden.us <mailto:gregg@vanderheiden.us>



> On Oct 4, 2022, at 3:53 PM, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
> 
> Hi Folks,
>  
> Picking up on the issue severity aspects:
>  
> > I understand it is not important for you.   But it may be for someone else.
>  
> The issue-severity sub-group went through most of the tests in the WCAG 3 FPWD and, with caveats, thought that it was possible to identify critical issues and (possibly) rank other issues.
>  
> That would be on the basis of an aggregate (of expert opinion/experience), with cross-checking against functional needs.
>  
> For example: Alt text for a functional image is (typically) going to be more important than a content image, which will be more important than a decorative image with unsuitable alt text.


This is where I have the problem.    Why is it assumed that a functional button is always more important than a content image.  
A function button may be "click to send feedback" and not have any real importance while the content might be what determines whether you have a serious problem or not. 
Even a submit button may be incidental if the user cannot determine whether they should submit something or not.


>  
> 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?  
>  
>  
> > you end up making the provisions less technology agnostic and more technology and current interface approach specific
>  
> Yes, but we’ve acknowledged we will need a technology specific level, and that could be the level at which we score (or assign severity).

We had techniques document for that.     As mentioned before—  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. 

>  
>  
> >  if you add contexts - where do you start and end?
>  
> Personally, I think context is the best basis for determining issue severity, but my main experience is to conduct this as process after you’ve identified the WCAG issues.
>  
> For example, using <h5>s for headings in the footer (after an <h2>) is unlikely to prevent someone doing one of the primary tasks on the website. Not wrapping heading text in heading tags in the main content is a bigger issue.

Perhaps - unless you are looking for something in the footer  - or that is where contact information is and your child is having an allergic reaction.  And perhaps the headings in the text were obvious without header tags (another context)

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?

It is easy to think of examples.  And some will be more common than others (e.g. headers in text vs headers in footers).   But we don’t want to just focus on most common.  That is the same trap that disability falls into all the time.  They are the less common.  And in this case - the less common may be the most important in different contexts.

Also - do we decide all contexts in advance ?    How can we?    Just the ones we think of get covered?  (Again) 


These context thoughts are all good thoughts - and we looked at these before.  Some we were able to identify - mostly contexts where it was impossible, or created a different problem.  We used those to create conditions on some provisions.   But beyond that it turned out to be a sink hole.     And had us making all sorts of specific assumptions that we would then use to make general rules…    

That is my concern. 

It also multiplies the number of provisions in WCAG  — which is already burdensome because there are so many.    Not sure multiplying them will help  (in addition to more -non tech agnostic and less future proof) 

>  
> It would need to be a process where we provide guidance (a bit like WCAG-EM) on selecting tasks/processes and how to determine severity/priority per method/test. I know that selecting tasks could be gamed, but so can selecting pages for a conformance statement.
>  
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.    

You could argue that external people would not accept internal contexts either - but that makes it worse.   As an author you would not know which contexts it was safe to use or not (unless all contexts are considered in advance and specific rules created for each.  )

Maybe it can work.  I just don’t see how. 

Sorry


PS - in looking at WCAG 2.x I see problems there too.   Some we might fix and some I don’t see how to.  But adding these seems to be adding more - not getting better.  

Good luck

g


> Kind regards,
>  
> -Alastair
>  
> -- 
>  
> @alastc / www.nomensa.com <http://www.nomensa.com/>