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

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 <mailto: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 <mailto: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 <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).
>
> 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
>
> John Foliot <mailto: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 <mailto:john.foliot@deque.com>
>
> Advancing the mission of digital accessibility and inclusion
> Michael Pluke <mailto: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 <mailto: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