RE: We should fix this Re: Level AA exceptions

I agree. Scope is the key for extending. We can pay attention to our decision history for suggested patterns.

-----Original Message-----
From: "Katie Haritos-Shea" <ryladog@gmail.com>
Sent: ‎8/‎16/‎2015 5:29 AM
To: "David MacDonald" <david100@sympatico.ca>
Cc: "Wayne Dick" <wayneedick@gmail.com>; "WAI Interest Group" <w3c-wai-ig@w3.org>; "Phill Jenkins" <pjenkins@us.ibm.com>; "Chaals McCathie Nevile" <chaals@yandex-team.ru>; "GLWAI Guidelines WG org" <w3c-wai-gl@w3.org>
Subject: Re: We should fix this Re: Level AA exceptions

Really well stated David. Thank you. +1
On Aug 16, 2015 8:03 AM, "David MacDonald" <david100@sympatico.ca> wrote:

In my experience, the reason we went from the priority system in WCAG 1 to the Level A, AA, AAA in WCAG 2 was because WCAG 1 was highly criticized for giving the perception of prioritizing one disability over another.


In my memory, at the time of WCAG2, blindness gaps were easier to test, measure and correct than many other disabilities. Barriers for the blind were brick walls, and the things that helped the blind also helped many other disabilities (Keyboard access, text alternatives etc, programmatically associated labels etc...), and so there is a leaning on those at Level A.


It's a very difficult thing to document rationale for every decision without risking a political minefield of appearing to prioritize one disability over another, but I think we may have to do it going forward ...  however, we need to realize that doing so will slow our process down because there will be very heated discussions in order to get consensus on (1) rationale (2) what to put in (3) where to put things. Consensus is a very delicate and difficult thing and if there is a miracle in the WCAG 2 it is that we achieved consensus, without one formal objection.


Each of us had things we would have liked to see different. For me, I wrote most of 1.4.8 which I wish had been placed at Level AA. For others in the group, they had things they wanted. 


But we all put our own personal agenda's AFTER the greater group consensus. I'm grateful to have been involved in the consensus process, without which, WCAG would never have gotten off the ground and included in laws around the world.


It was certainly not perfect, but so far I haven't seen a better process proposed. I'm hoping with all these ideas we can improve the process, and still reach the illusive and critical goal of consensus, so that the outside world can have confidence in our recommendations.  


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn
www.Can-Adapt.com 
   
  Adapting the web to all users
            Including those with disabilities


If you are not the intended recipient, please review our privacy policy


On Sat, Aug 15, 2015 at 3:24 PM, Wayne Dick <wayneedick@gmail.com> wrote:

In response to Phill. Perhaps, and I am really not sure. if a final normative statement of the rationale for classification should not be published with a WCAG extension. I realize it is process not guideline, but it is so essential to the credibility of the process it should be included as a formal glossary term that gives clear criteria. That is for example: A criterion is classified Level A if there is an identifiable class of people with disabilities who cannot use a website if the criterion is not met.  A criterion is classified as Level AA if there is an identifiable class of people with disabilities can use the site but only with severe difficulty if the criterion is not met. A criterion is Level AAA if the site is usable by all disabilities identified by WCAG, but it will provide equal effectove access for some identified class of people with disabilities.


The concept of accessibility is independent of feasibility of implementation.  Standard print on paper is inaccessible almost all disabilities stemming from visual impairment.   It may not be feasible to produce large print or braille versions of all publications, but the lack of feasibility does not create a situation in which standard print could be interpreted as accessible. 

I was clear that I was referring to American law when mentioned the concepts of fundamental alteration and undue burden, concepts I understand quite well from managing the accessibility initiative for a 23 campus, 450,000 student system. It appears that WCAG WG employed similar concepts when classifying success criteria as Level A, Level AA and Level AAA, but there was never a written justification of the decision process.  That is a credibility gap, and it is serious. 

When did feasibility trump accessibility in classifying criteria and why?  It is clear this was done, but there is no well defined process.  


I actually felt included in the WCAG 2.0 process, and I contributed many suggestions that were adopted.  I am getting tired of people who participated in writing WCAG WG explaining what they really meant.  The normative language should stand alone without interpretation from the authors.  That is why in actual law there is a judiciary that interprets law independent of the original authors.



One of the deep flaws in the WCAG process is the exceptional defensiveness of the authors, and WCAG WG taking ownership of every minute detail of interpretation. If we succeed in extending to WCAG 2.0, I sincerely hope that we can be open to interpretations that may differ from our original vision.  Guidelines only live as long as they are open to reinterpretation to reflect changed realities and new discoveries.  I don't see this happening with the current WCAG 2.0. I think it is harming W3C leadership in the area of accessibility.


Wayne



On Sat, Aug 15, 2015 at 12:00 AM, Chaals McCathie Nevile <chaals@yandex-team.ru> wrote:

TL;DR: Multiple factors for giving success criteria a level, without documenting the decision rationale, causes a problem. We should fix that.

I suggest that part of the long-term fix (which would be WCAG 3, rather than an edited version of WCAG 2 which may or may not be worth doing meanwhile) is to reduce the number of factors.

More details after the recap of discussion…

On Fri, 14 Aug 2015 21:39:52 +0200, Katie Haritos-Shea GMAIL
<ryladog@gmail.com> wrote:


From: Phill Jenkins [mailto:pjenkins@us.ibm.com]Sent: Friday, August 14,



Gregg Vanderheiden wrote:

[…setting level decided on a balance of factors including how important something is, whether it can be applied to all sites, and how hard that is… it is not true that all essential requirements are level A, and level AA requirements can be considered strictly less important…]

Hope this helps



Sure, but mostly what I already posted.  What's missing is the documented rationale for why an individual particular SC is considered Level AA.  We have all the "possible" factors, being 'Essential" was indeed one of the factors, But we don't have documented which of the many possible factors were considered for this particular SC. Yes we know in general that all these factors may have been considered for all the SC.  but, For example, again,
      Why was SC 1.4.3 Contrast Minimum assigned AA?



KHS: I do not recall why this was delegated to AA.



      Why was SC 2.4.7 Focus Visible assigned AA?



KHS: It is my recollection that this SC was placed at Level AAbecause of the default browser behavior (I am one who lobbied for
it to be at Level A) – as you suggest Phill.



Many feel it is essential, but mostly handled by the browser, is that why?  where is that written?



KHS: I suspect you could find it in the minutes, I am not sure it
was officially documented other than meeting minutes.

...

Again, is having a synopsis of the rationale for why each individual particular SC was assigned Level AA of value to everyone on this list?



KHS: All I can say is it made sense via consensus to the group of people who were active in the Working Group – and those who provided review and feedback – at that time in history based on the technology as we knew it then.


I think this last statement is an accurate summary of how we got to where we are.

This was done about a decade ago, and the Web has changed.

We have (and I believe will always have) a hard time getting enough knowledge into the group - particular issues seem to be that we lacked sufficient strength in dealing with various "cognitive accessibility" issues, some low vision issues, we certainly have a strong bias towards english-speaking countries and their most familiar neighbours, and so on.

And a decade after the people in the room made their best effort, others are trying to use that work, with its known and unknown but mostly unstated weaknesses, to build requirements.

For those people - whether they are governments writing regulations as in Section 508, or companies producing internal policies for their developers (which is more relevant to my case), understanding the importance of a given success criteria to people with disabilities is critical.

Knowing what a group of people thought ten years ago about how applicable this was to websites in general, is almost irrelevant except to understand why something seems to have a "lower priority" level than it "should".

In the same way, knowing what we thought ten years ago about how hard something is doesn't have a lot of direct relevance to what should be required in a given situation now. Different users basing requirements on WCAG will have very different approaches to what is a "reasonable effort", and in any case there are genuinely different technologies and solutions available now.

It would be very valuable to document for WCAG how important each success criterion is to whom (sometimes there are different levels of importance for different user groups, as Gregg already noted).

The WCAG working group *should* do that work - it is one of the most important ways that WAI can help policy-makers at all levels, who are one key audience of our work.

WCAG 2.0 has not been updated for a long time, and it seems that pattern will continue (it was the same for WCAG 1). Providing some guidance for people to decide where to focus their efforts first is valuable. I think an important lesson is that we need to explain very clearly why each requirement is there and how it got assigned a particular "level", so people making downstream decisions 7 years later can judge whether they are adopting something important, something that got overtaken by technology development, or what…

cheers

Chaals

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
   chaals@yandex-team.ru - - - Find more at http://yandex.com