- From: Wayne Dick <wayneedick@gmail.com>
- Date: Sat, 15 Aug 2015 12:24:41 -0700
- To: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Cc: Phill Jenkins <pjenkins@us.ibm.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
- Message-ID: <CAJeQ8SCws=obDtieP09GUrWp3G-EEArWwLxJC28AH33vjXO3_Q@mail.gmail.com>
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 > >
Received on Saturday, 15 August 2015 19:25:15 UTC