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

I’ll throw in my two cents – what has been most frustrating for me has been that we have been working on these criteria for over 3 years in the case of the mobile task force and we solicited help from all W3C members and welcomed invited experts to the table.  Unfortunately some of the larger companies that now are raising concerns did not jump in before now even though we requested and welcomed their assistance.  These companies have the ability to dedicate resources to this task and we could be further along now and have less at risk success criteria had some of these organizations with concerns come to the table sooner.  At each stage over the last three years as new people have come into the TFs and lists we have to repeat and reiterate the same concerns and arguments over several times and go back and forth over wording sometimes reverting back to what we had before.  Releasing the WCAG 2.1 FPWD certainly received more high level attention than original mobile TF note in my opinion and finally brought out the stakeholders that we needed access to and dialog with all along.

Best Regards,

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | LinkedIn<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Download our CSUN Presentations Here!<http://info.ssbbartgroup.com/CSUN-2017_Gateway-Sig-Slide-Decks-2017.html>

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Thursday, April 06, 2017 1:40 PM
To: Michael Pluke
Cc: GLWAI Guidelines WG org; Wayne Dick
Subject: Re: Low Vision and COGA should Drop Support for WCAG 2.1 if the AG WG is not willing make real change.

> I think what Wayne is suggesting is similar to the extension model.
​>​
​> In other words, basic wcag 2.1 address some disabilities  well, with some benefits for other disabilities. People should use the extensions when it is important to include everyone.

Hi Lisa,

I would strongly oppose any return to piecemeal "extensions" such as that, which will have the net effect of both ghetto-izing impacted user-groups, as well as essentially ensuring that *NONE* of those extended SC will be taken up by larger organizations. You would also likely find that regulatory bodies would also 'discount' the extensions as "supplemental" as well (witness what happened to AAA SC), and may very-well not gain the force of any regulatory backing. I fail to see how that would benefit those core constituencies.

This was the argument presented 14 months ago when we shifted direction of this WG towards a dot.extension evolution, and while this WG can continue to debate the wisdom of our change of direction taken last summer (which included a re-chartering that took our attention and focus away from other important activities), please note that I for one will protest quite strongly if we start second or third-guessing ourselves and seek to return to the previous model of 'extensions'.

**********

> Right now I live in a country that has a policy that leaves me out.

Hi Wayne,

While this is indeed concerning, what can the W3C do about this? That is a serious queston.

The W3C, and the AG WG, are not regulatory bodies; this group can neither grant nor remove "rights", nor can it claim to be establishing a legal requirement anywhere - that is up to governments and other regulatory bodies to do. The W3C did not make WCAG part of the refreshed Section 508 (if they could have done that, I don't think they would have waited 16 years to do so) - it was the US Federal Government and their internal processes that both delayed the adoption, and also mandates specific entities to compliance - the W3C isn't in that game.

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

Interference? Hang on a minute... there is absolutely *NOTHING* that restricts user-groups of any stripe to go off and make their own guidelines and recommendations elsewhere. Choosing to do so inside of the W3C has supplemental benefits, but there is nothing stopping you from writing the "Wayne Dick Web Accessibility Guidelines" - anyone could do similar. The trick is getting those recommendations adopted by developers at scale - and eventually (one presumes) entrenched in laws and regulations. Failing to achieve that is simply an exercise in wishing and hoping.

The advantage of doing this work inside of the W3C is that it has wider review and input, and whatever finished product we arrive at will be looked at with serious intent, because it is being published by an entity with a history and pedigree.

However, getting published at the W3C has its costs as well, and one of those costs is that you can't always get everything you want - every stakeholder must be listened to and their concerns need to be understood and addressed as well. Consensus and compromise are critical here, yet repeatedly some members of both COGA and LV approach this list and process as an us-versus-them activity, and then take on the position of aggrieved party who are being ignored or turned away.

> This discussion is upsetting.

You're darned right it is.

A large number of people from all kinds of backgrounds dedicate (often unpaid volunteer) time and effort to work on this activity, towards a shared common goal - making the web *more* accessible (and not "perfectly accessible"), and rants, diatribes, and accusations that some of us are simply leaving LV (or COGA) folk behind is counter-productive. When somebody like myself or others point out problems, it is not because we don't want to succeed, in fact quite the opposite - if I can see a problem, I'll bet a tidy sum others will as well (go look at some of the feedback we've received from non-participants so far).

*********
Microsoft:

   Testable: a. Easily and successfully are highly subjective terms. Please remove.

*********
Oracle:

   Printing: Browsers do not seem to use the page zoom level when printing. This seems like a user agent requirement and not a content requirement.

*********
Accessibility Foundation NL:

   Printing: Isn't this a browser functionality? Isn't this very hard to get right across multiple user agents and highly depended on how the particular user agent handles it? How much influence do web developers really have here?

*********
WebAIM:

   Interuptions: This success criterion is at odds with 2.2.1 and 2.2.6 which prescribe pop-ups and notifications to inform of time-outs. It also conflicts with the new SC 3.2.8 (Change of Content) which requires that users be notified of content changes. How can authors inform users of a time-out or content change to meet one success criterion when such notifications are disallowed by another?


Most of us understand the frustration being expressed here, but I will politely suggest you are "dumping" on the wrong people - we've all shown up here to try and make things better, not worse, and suggesting otherwise is simply slamming the door in the face of your friends.

A case in point was on our teleconference today, where I actually was pushing back on minimum target sizes and what happens when it introduces horizontal scroll (because, honestly and truthfully, I've heard you say how that - at least as I hear it - is the single largest issue that LV users grapple with - because you did the research and shared it with us).

But I've yet to hear a solution to the problem I presented: an onscreen keyboard with 10 "keys" across the first row @ 44px will scroll horizontally on many mobile devices, and "reflowing" the keyboard keys breaks a visual convention (likely bad for COGA, and will simply not be taken up by web designers, who already feel 'constrained' by some of our requirements). As I noted on the call, this is a King Solomon decision/problem, because personally I cannot see a way out today, but in the context of this email, note that I actually stood up for one of the LVTF's larger issues - so accusations that this group doesn't care or isn't willing to address LV concerns is simply untrue.

This is hard, there is no question about it, but hard-line responses without some degree of flexibility will likely be met with the equal force of resistance, if not within this working group, certainly in the wider world of non-expert developers and their senior administrators.

As a former manager used to say to me, we cannot let perfect be the enemy of good, and I will suggest that this is a very good idea to keep in mind as we continue to move forward.

Respectfully,

JF


On Thu, Apr 6, 2017 at 11:11 AM, Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>> wrote:
If this debate continues, which I wish it would not, then we must keep a sense of perspective. We shouldn't be making statements like "State explicitly that Low vision and Cognitive disabilities are not included" in WCAG 2.0 (or 2.1).

When we created the European EN 301 549 standard we had a "Functional Performance Statement" (FPS) titled "Usage with limited cognition" which expressed the general need to meet the needs of persons with cognitive disabilities. To help people interpret this we created a table that mapped WCAG 2.0 SCs to these FPSs. Therefore, long before this controversy exploded we identified 17 SCs that directly supported the needs of people with cognitive disabilities and a further 15 that provided some secondary benefits. Although this mapping was not a mandatory part of the standard, and therefore it may have received less scrutiny, nobody challenged this mapping during the extensive reviewing of the standard. The identification of which SCs were beneficial was largely done by looking at "Understanding WCAG" statements that explained how an SC was beneficial.

On this basis, saying that cognitive disabilities are not included in WCAG 2.0 is very badly misleading.

I'm sure that there is universal acceptance that there will be significant accessibility barriers that people with Low Vision and Cognitive Disabilities will still encounter, after WCAG 2.1 is completed. Knowing this is one thing, being able to draft SCs that solve these issues is a much more challenging task. However abandoning 2.1, which should enhance overall accessibility for a wide range of users, would benefit precisely nobody.

Currently very many countries around the world incorporate WCAG 2.0 into their laws in order to ensure that public sector websites meet the minimum level of accessibility that WCAG 2.0 should guarantee. At least in Europe, there is a desire to incorporate WCAG 2.1 into the law related to public sector websites and mobile applications. If WCAG 2.1 included SCs that fail to adhere to the agreed (and well understood and accepted) criteria that the text of an SC must meet, I am certain that this would lead to a rejection of WCAG 2.1 and a reversion to WCAG 2.0. Again, as I said in my earlier email, who is going to benefit from that - precisely nobody.

If we are totally unable to create enough LV and COGA SCs that meet the necessary criteria, then we may need to see how the good guidance that we have already identified can be packaged in a form that may be able to influence the design of content that is more LV and COGA friendly. But this would be in addition to WCAG 2.1, not instead of. In Europe we have already created a guidelines document related to COGA and ISO are also heading towards their own guidance standard for COGA.

Mike

Get Outlook for iOS<https://aka.ms/o0ukef>
_____________________________
From: Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>>
Sent: Wednesday, April 5, 2017 11:51 pm
Subject: Low Vision and COGA should Drop Support for WCAG 2.1 if the AG WG is not willing make real change.
To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>


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 did worse than nothing for low vision and cognitive disabilities. It created the illusion that we were helped when we were being left out. 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.

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.
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.

​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.

With that admission, people with these disabilities could then proceed to devise guidelines that would help us without the interference of 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.
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.



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion