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

Advancing the mission of digital accessibility and inclusion