W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

RE: Low Vision and COGA should Drop Support for WCAG 2.1 if the AG WG is not willing make real change.

From: Michael Pluke <Mike.Pluke@castle-consult.com>
Date: Thu, 6 Apr 2017 11:13:40 +0000
To: lisa.seeman <lisa.seeman@zoho.com>, Gregg C Vanderheiden <greggvan@umd.edu>
CC: Dick <wayneedick@gmail.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
Message-ID: <ac1afb0ced0d4f5e9d9c88e48eba6cb7@E15MADAG-D05N03.sh11.lan>
Please can we stop this line of discussion!

I was not involved in the creation of WCAG 2.0 so cannot comment on what took place, but I really seriously doubt that there were active efforts to exclude the needs of LV and COGA users. I think that Gregg has identified the root of the problem – during the development of WCAG 2.0 it was, with the best will in the world, extremely difficult/impossible to draft LV/COGA SC that met all of criteria necessary for the creation of a valid SC.

Author-burden may have been an issue then and is also being raised now. I think that this issue is a grey area and I believe that this is something that the LV and COGA members can try to lobby for a more permissive approach than may have been done during the development of WCAG 2.0. But from my reading of the objections to the COGA SC proposals, author-burden is not the primary focus of the objections – it is all the rest (important access issues, testability, being essential, being applicable to all Web sites and types of content, being reasonably achievable by content creators, etc.).

I believe that most of our SCs are receiving objections because they:

  *   Are overly ambitious – trying to solve all the problems related to a particular topic with extremely long multi-element text that tries to address several aspects at once. With perhaps a couple of exceptions, WCAG 2.0 SCs are not like this – for a very good reason. The wider target an SC attempts to address the greater is the chance that there will be ambiguities and exceptions that cannot be fixed (even by adding even more words). Currently a range of WCAG 2.0 SCs taken together cover MOST of a broader issue, but there will be other aspects of that broader issue that will not be addressed. That is something that has to be accepted.
  *   Contain vague concepts – “simple”, “important”, “clear”, etc. These are very important ideas in relation to COGA, but they are not directly testable and attempts to define them are almost certain to be inadequate to cover all of the real-world practical realisations of these concepts.
  *   Rely on authors or testers having access to tools or technologies that are, as yet, either not yet built or not widely available and which have not been proven to meet the needs for which they are being proposed;
  *   Are simply not testable in ways that most people would accept as appropriate (often for the reasons above).

I really think that every member of the TFs really needs to “wake-up and smell the coffee” (to break a COGA metaphorical language rule) and realise that the problems are not due to all the people outside the TF being unreasonable. The problems are simply due to the current scope and wording of the proposed SCs – and that is for the TFs to try to fix.

I know that in the COGA TF many people are currently working very hard to try to fix the SCs. However, I fear that unless everyone forgets the “they’re all out to get us” thinking and accepts that there are really significant problems in many of the SCs and that it is up to us to fix them (accepting the validity of the sorts of issues raised in the above bullets - especially the first one) then I am very afraid that we will fail to achieve anything that might otherwise have been achievable.

We have to accept that what is realistically achievable will only ever be a fraction of the accessibility issues experienced by COGA users. Persisting in the belief that we can get acceptance for SCs that remove most of the barriers that COGA users experience is likely to lead to a failure to address any of their needs – resulting in an even greater feeling that nobody cares. Let’s not go down that route!

Best regards


From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: 06 April 2017 09:44
To: Gregg C Vanderheiden <greggvan@umd.edu>
Cc: Dick <wayneedick@gmail.com>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
Subject: Re: Low Vision and COGA should Drop Support for WCAG 2.1 if the AG WG is not willing make real change.

Hi Gregg

I am not sure going over old wounds is very helpful now, but I do feel the need to respond to some of the claims bellow.

As I recall the wording changed considerably as a response to the formal objective on cognitive being left out. Until then WCAG claimed to define and address the requirements for making Web content accessible to those with learning difficulties, cognitive limitations and others (see https://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0368.html)

My interpretation and recall of what it was like working on 2.0 is very different. As I remember the biggest reason for rejecting SC for coga was "author burden" and "author freedom" - something that affected other SC as well but were not consistently applied. We tried very hard to minimize this such as developing CSS techniques and RDF techniques , but they were all rejected. You will notice a lot of the members of the working group (at the time) and I think all the experts that you mentioned were part of the objection and frustrated with the process. I think this might show that there was less consensus.

more comments in line

All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>

---- On Thu, 06 Apr 2017 04:49:09 +0300 Gregg C Vanderheiden<greggvan@umd.edu<mailto:greggvan@umd.edu>> wrote ----
This language is misleading (paragraph 1 ) and inaccurate Paragraph 2 — and does nothing to advance accessibility except throw chaff in the air.

Gregg C Vanderheiden

On Apr 5, 2017, at 6:50 PM, Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:

The assumptions of WCAG 2.0 cannot support low vision or cognitive disabilities in ways essential to access.  A page can pass WCAG 2.0 at level AAA and fail to be usable by people with low vision and cognitive disabilities.

WCAG 2.0  at level AAA does not make everything accessible to ANY everyone with ANY disability.   There are people who are  Blind, have low vision, are  hard of hearing, deaf,  and have cognitive, language, and learning disabilities who cannot use pages that are AAA.      So the statement above is true — but it is true for all disabilities.

There are also people with ALL lf these disabilities that CAN use pages with AAA and even AA.

Lisa: this is not really true. there are many different cognitive disabilities. Although people with a mild learning disability like ADD can us most AA content, most cognitive disabilities will only find this content usable if other principles have been applied that are  outside WACG AA or AA (sometimes this is achieved by user testing - but that is not thanks to WCAG)

WCAG 2.0 did worse than nothing for low vision and cognitive disabilities. It created the illusion that we were helped when we were being left out.

We were left out?

Lisa: yes. were left out and are left out. And as technology become more important to daily life this means more and more coga LV people are needing help to perform daily tasks such as making a doctors appointment or holding a normal job.
This is very real  and it is getting more and more urgent.

This may be hard to accept if you worked hard on WCAG 2.0. However, it is time to accept this fact and start solving the problem.

If you read WCAG 2.0 you will find that it is NOT hard to accept if you worked on WCAG 2.0 —  in fact we made a point of saying in the introduction to WCAG that  WCAG is not able to address the needs of people with all types, degrees, and combinations of disability.

But the working group spend over 3 years trying to find and put in as many provisions as it could on cognitive, language, and learning disabilities.  It brought in experts, it combed the literature, it engages leaders in the area.       We faced the same problem you did with this area.   Whereas we found many things that could help people with cognitive, language, and learning disabilities,  it was hard to find things that were consistent and testable.

Saying we did not look at this or consider it is simply rewriting history.

You are about to embark on the same painful journey we did.   You will identify many things that can be done to some web pages or some things or things that can always help but cannot be quantified or tested etc.    Making things simpler is always good — and it is my opinion that almost all content could be made 20% simpler with no loss of content or function.   But It can’t be made 20% simpler again after that without loss.    And what does simpler look like.   And what is the measure.   And simpler isnt accessible.   And nothing is simple enough that every one can understand it (just like 200% OR 400% larger cannot be seen by everyone.   But with magnification we can measure it.    How do you measure simplicity?       That is the killer.

It is not that we did not care about cognitive, language, and learning disabilities.   It is not that we didn’t spend time on it.  We actually spent more time on it than any other disability.  But we could not find anything more that could be turned into and SC.    So we made the rest into advisory techniques.

I hope that you are able to find more than we did.

But you will find it a very painful process.    Painful because you want to — but it is really hard to find things that are quantifiable and testable — and you cannot REQUIRE people to so things where you cannot tell them (and they cannot tell themselves ) if they have done them.

I wish you well.    I will help as I can.    But don’t let your zeal to get thing in — push you to forget the requirements - or they won’t fly and it will wreck you ability to adopt those things that do qualify.

And stop throwing rocks at those who went before you.   If you find things they did not - then congratulate yourselves.   But don’t denigrate those that spent so many years of their lives trying before you.    You will have more sympathy as you try to get things all the way to the finish line.   You will find you have to leave many on the table if you don’t want to graduate things that do not qualify.

There is no point of 2.1 continuing the false illusion that it provides meaningful help, when it does not.

Low vision needs a few fundamental things. Personalization of text: font-family, spacing, color. The precise limits are these: any font family the user chooses, spacing that has been proven to be useful, and 16M colors. We need ability to enlarge significantly at least  400% with word wrapping. We need single column access. That is what is needed. If the WCAG 2.0 assumptions cannot support this need then we need to change the assumptions.

What assumptions are you referring to in particular?

I am sure there are similar bedrock issues for Cognitive Disabilities.
The basic idea of accessibility for a disability is that a person with the disability can use the resource. Right now WCAG does not support access for the majority of people with visual disabilities and most people with cognitive disabilities. That is just a fact. COGA and LVTF have documented this decisively.

Not sure about majority.   And I assume you are talking about use without AT?

​If the AG cannot change some WCAG 2.0 assumptions then would the W3C just stop claiming they make guidelines that provide access to people with disabilities when it fails to do so. Just say the WAI gives guidance on how to help some disabilities​. State explicitly that Low vision and Cognitive disabilities are not included.

??????     Are you talking about assumptions ?   or are you talking about the basic requirements for an SC.     Those requirements are not anything that the AG (?) made up.  Those are the definitions of a Criterion.       Something that is a criterion must be testable or it can’t be a criterion.      And if you say it applies to web content - and must be applied to all web content then it must indeed be implemented able on all web content etc.

With that admission, people with these disabilities could then proceed to devise guidelines that would help us without the interference of WAI.

You ARE the WAI.    We are the WAI.

Right now WAI is harming these disabilities because developers and legislators believe that if they follow the WCAG guidelines than most disabilities are covered. This is false. Low Vision and Cognitive Disabilities are not covered.

They are partially covered.  Everyone knows they are not fully covered.  This was made clear by every member of the WCAG 2.0 Working group that worked on WCAG and 508  etc.

The WAI just failed these disabilities. Live with it. WAI can do something about it, live in denial, or leave the field to people who know how to help.

No comment.        Except that I know that the WAI and the WCAG 2.0 WG all hope that you can succeed in finding more qualified SC for these groups.

I still think that you will find that MOST of your ideas and that MOST of the things that can be done for people esp with cognitive, language, and learning disabilities cannot qualify as SC.    And this is why I was URGING this group to focus not on SC but on putting together a great document on how to make things more accessible to these groups.    Not one limited to SC but one that could write about what should be done without all the limitations that SC have on them.     I still hope that this can be done.

Good luck with the efforts to find more things that will help make things more accessible.    When you are done content STILL will not be accessible to all.   But it will be accessible to more.

Just don’t weaken all the work by including things that do not qualify as criterion  -  because they are good ideas and will help.    It will not lead to adoption of your work as anything that can be required if it cannot be determined reliably when they are met or if they are not generally applicable etc.    And that would be the biggest loss.


Received on Thursday, 6 April 2017 11:14:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 April 2017 11:14:17 UTC