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

When the WAI started its push for harmonization it ceased its ability to
claim it was independent of regulatory bodies. It became a lobbying group.
WAI has significant responsibility for laws, policies and regulations based
on WCAG. In the US that excised low vision from the disability groups with
effective representation under Section 508.



On Fri, Apr 7, 2017 at 5:18 AM, Gregg C Vanderheiden <greggvan@umd.edu>
wrote:

> Hi
>
> It is NOT the first public working draft.
>
> It is the first  FORMAL CALL FOR PUBLIC REVIEW.
>
> This should be made clear.   All of the editors drafts are open to the
> public.    (at least they always were so I assume this is still true)
>
> Gregg
>
> Gregg C Vanderheiden
> greggvan@umd.edu
>
>
>
> On Apr 7, 2017, at 4:53 AM, Joshue O Connor <josh@interaccess.ie> wrote:
>
> I'm glad to see this thread diverge from its original content.
>
> Please initiate/use separate threads to continue this conversation.
>
> Thanks
>
> Josh
>
> Patrick H. Lauke <redux@splintered.co.uk>
>
> 7 April 2017 at 08:29
>
>
> Part of me thinks this is inherent with the way (or perhaps the perception
> of the way) W3C/WAI works, with task forces, membership to working groups,
> invited experts etc, rather than working completely in the open / open to
> all (while of course there's no hard door slam for non-members, it's still
> the impression that the average developer may have...and it's exemplified
> by having a First *Public* Working Draft, which suggests any previous work
> was no "public").
>
> P
> Jonathan Avila <jon.avila@ssbbartgroup.com>
>
> 7 April 2017 at 03:59
> 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
> 703.637.8957 <(703)%20637-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 <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).
>
>
>
> 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
> John Foliot <john.foliot@deque.com>
>
> 6 April 2017 at 18:40
> > 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).
>
>
>
> 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
>
>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
> Michael Pluke <Mike.Pluke@castle-consult.com>
>
> 6 April 2017 at 17:11
> 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>
> Wayne Dick <wayneedick@gmail.com>
>
> 5 April 2017 at 23:50
> 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.
>
>
> --
> Joshue O Connor
> Director | InterAccess.ie <http://interaccess.ie/>
>
>
>