- From: Katie Haritos-Shea <ryladog@gmail.com>
- Date: Sat, 8 Oct 2016 22:58:52 -0400
- To: Wayne Dick <wayneedick@gmail.com>
- Cc: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAEy-OxH6wi5eGK2h4LgH8uANiXMG1rToAfMCyhyHUgc95rXK2w@mail.gmail.com>
Wayne, Somehow I missed seeing and responding to this important point. I am sorry about that. Is the SC set enough to be helpful and useful to address the disabilities that were (sort of) left-out in WCAG 2? Keeping the promises made to specifically address the user needs of these disabilities - in a meaningful way - matters. We should, must, follow through..... Katie Haritos-Shea 703-371-5545 On Oct 6, 2016 10:16 AM, "Wayne Dick" <wayneedick@gmail.com> wrote: > The threshold effect. > > This is why fixed dated cycles are problematic. There are guidelines that > exist in groups and are useful alone. 1.1.1, 2.1.1 and 2.1.2 are one > example. If you are non visual you cannot use the keyboard without knowing > where your focus lands, and you cannot use the keyboard long with traps > everywhere. > > In the case of cognitive and low vision you need entire sets of content > changes to get real access. It is not a question of all or nothing, it is a > question of enough to be something. I don't think the LVTF is close enough > to a quanta that works to say, "Here is a minimal effective set." > > Why is this true? Many disabilities are not as on or off as visual vs. > non-visual (I know there are subtleties to non-visual access). Of a set of > say 7 accessible content criteria maybe 3 or 4 are needed help most > individuals, but that 3 or 4 criteria change a with the individual. For > most individuals in these groups if you give them 2 of 3 needs, you might > as well give 0 because the partial set will prevent access to something > important like reading. > > Once we have all disabilities covered, we can discuss periodic release > goals. Right now we need to get basic access working for cognitive and LV > and a 2-year plan is no enough. > > Wayne > > > > On Thu, Oct 6, 2016 at 5:34 AM, White, Jason J <jjwhite@ets.org> wrote: > >> +1 to David’s comments (quoted below). >> >> >> >> *From:* David MacDonald [mailto:david100@sympatico.ca] >> *Sent:* Thursday, October 6, 2016 7:03 AM >> *To:* GLWAI Guidelines WG org <w3c-wai-gl@w3.org> >> *Subject:* Re: charter update with two year cycle >> >> >> >> I think the model of stable technology agnostic Success Criteria which >> are developed carefully with thorough review over a number of years, and >> nimble up-to-date techniques that are on a 6 month cycle is reasonable. >> >> >> >> If I ask people "would you like WCAG to be up to date" everybody of >> course says "yes". When we explain the gentle balance between stable long >> term Success Criteria and flexible up to date techniques, I generally find >> they understand that the model has a good update mechanism. >> >> >> >> I think its time to be working on more SCs and we are doing so, and we >> are working under this WCAG 2.0 model. >> >> >> >> Perhaps Silver will be able to propose another model that will be better, >> but as it stands, the WCAG 2 model is the best I've seen and its one of the >> most successful standards ever. >> >> >> Cheers, >> David MacDonald >> >> >> >> *Can**Adapt* *Solutions Inc.* >> >> Tel: 613.235.4902 >> >> LinkedIn >> <http://www.linkedin.com/in/davidmacdonald100> >> >> twitter.com/davidmacd >> >> GitHub <https://github.com/DavidMacDonald> >> >> www.Can-Adapt.com <http://www.can-adapt.com/> >> >> >> >> * Adapting the web to all users* >> >> * Including those with disabilities* >> >> >> >> If you are not the intended recipient, please review our privacy policy >> <http://www.davidmacd.com/disclaimer.html> >> >> >> >> On Thu, Oct 6, 2016 at 2:46 AM, John Foliot <john.foliot@deque.com> >> wrote: >> >> While I hear, respect and >> >> traditionally >> >> trust people like Gregg, Lisa, Katie and others, I get the distinct >> impression that they are all working on an "All or Nothing" sum-total >> proposition, where >> >> they believe >> >> we need to get *all* the new proposed Success Criteria into the next dot >> release of WCAG for fear of "missing out". Why that is is beyond me, as >> there is nothing in the proposed Charter that suggests that. >> >> >> >> Yes, developing new Success Criteria is hard work, and yes, if we were >> to set out to process all of the current ~50 draft proposals coming from >> the various Task Forces into the next release of WCAG, then by all means it >> will take longer than 2 years. >> >> >> But we won't be working on all of the new SC simultaneously, and it >> dumbfounds me that we would want to hold back 4, 8, >> >> or >> >> 10 "complete >> >> d >> >> " SC in a 2 year period until the balance of the SC are >> >> finalize >> >> d >> >> . That serves nobody in any effective >> >> or productive >> >> way. >> >> As a Working Group, we will need to prioritize our work, and not try >> and eat the elephant in one sitting - that doesn't work when eating >> elephants, and it won't work if we want to keep Accessibility Guidance up >> to date and current with emergent and existing technology today. >> >> >> >> WCAG 2.0 is woefully out of date today; not that the current SC are >> 'bad', but rather we have identified clear gaps that need to be closed now >> - not 5+ years from now. The whole point of "dot >> >> (point) >> >> releases" in software and standards development is to release what is >> ready now, so that it can be taken up and used >> >> by developers >> >> now, not some hopeful time >> >> " >> >> down the road >> >> " >> >> when we've resolved >> >> ALL >> >> the discussion around >> >> ALL >> >> of the newly proposed SC on the table today >> >> . >> >> By identifying fixed and specific "ship dates" now and into the future, >> we can reliably ship what's ready when it's ready, on a date that everyone >> who cares can count on, and keep working on what is still not ready for the >> next "ship" date, or the one after that, or the one after that. >> >> >> >> Allen Hoffman wrote: >> >> >> >> > when we touch the success criteria we effect many many more associated >> activities and the knock-on effect can take a significant time to be >> understood and completed. >> >> >> The whole point of the >> >> proposed >> >> dot release plan is to ensure that we maintain a backward compatibility >> 'manifesto' as part of the go-forward effort. We won't be "changing" any of >> the Success Criteria for the 2.0 document, >> >> AND WE NEVER WILL >> >> . >> >> WCAG 2.0 will always remain WCAG 2.0. >> >> >> >> We *may* modify the text of >> >> some >> >> existing SC to encompass more (eg: color contrast on more than just >> *text*, but to now include actionable graphics/icons), but *if* an entity >> adopts >> >> and develops to >> >> that change, then they are working towards complying to WCAG 2.1, and >> *NOT* WCAG 2.0. If you don't need or want to add actionable icons into the >> class of content that needs to meet a minimum contrast requirement, you >> won't have to to >> >> still >> >> meet compliance to WCAG 2.0 - because of the backward comparability >> design. >> >> >> >> >> >> >> >> We >> >> also >> >> have a lon >> >> g >> >> er-range plan, and that's known today as Project Silver. >> >> On that effort, yes, time and patience of the kind Gregg notes will be >> required, but while we take the time and patience to get that right, we >> also have an ongoing need for current guidance and success criteria >> *TODAY*, which is what the dot extension release schedule seeks to address. >> >> >> >> Earlier today, Katie Haritos-Shea wrote: >> >> > WCAG 2 is a standard that >> >> >> >> developers use to improve access for users >> >> Correct! >> >> >> >> It is >> >> NOT >> >> a legal document, civil-rights guidance, or a W3C-based companion to the >> Section 508 refresh that is currently 16 years in the making. >> >> >> >> >> >> Yes, we need to be mindful of the needs of the regulators, but they are >> but one constituent that WCAG serves >> >> , and not the primary one at that >> >> . >> >> There is absolutely nothing in a 2 year dot extension release schedule >> that would prevent >> >> governmental >> >> entities from pointing to or referencing WCAG 2.0 (circa 2008) today, >> next month, or in the year 2020, and deliberate and conscious foot-dragging >> serves none of the developers or users that WCAG is intended to benefit >> >> , by artificially holding back actionable Success Criteria that is >> ready now, or in 2 years from now, or 4 years from now (etc.) >> >> . >> >> As the early research of Project Silver has discovered, we already have >> large web organizations building out their own internal accessibility >> guidance and policies in the vacuum that is the 8-year-old WCAG 2.0, and >> waiting another 5 >> >> + >> >> years to add Requirements and Success Criteria to address issues around >> Web Applications and Mobile/Responsive Design (to name but 2 urgent >> requirements today) will likely result in an even harder time reconciling >> the W3C Accessibility Guidance and those internal documents >> >> springing up >> >> in organizations >> >> who want to do MORE than just the bare minimum, and who are today >> adding new internal requirements to their accessibility requirements lists >> >> . >> >> >> >> >> >> As an example, at Deque we are already looking at emergent proposed SC >> from the various task forces, and adding key elements from that work to our >> internal testing and evaluation methodology; today as "Best Practices", but >> in anticipation of adoption at the W3C as a formal Success Criteria, or in >> the case of "Mobile" simply because our clients need and want *something* >> TODAY, not 5 years from now. >> >> >> >> I posit that we run the risk of letting WCAG 2.0 become as relevant to >> daily web developers in the next 2, 4, 6, (etc.) years as the beleaguered >> Section 508 is today if we don't start matching and reflecting the reality >> of web development on the ground today, and at the speed that those changes >> are happening. I fail to see how that would benefit anyone, least of all " >> >> ... >> >> developers >> >> (who) >> >> use >> >> (WCAG) >> >> to improve access for users >> >> ". >> >> >> >> Let's also not forget who the real primary beneficiaries of our efforts >> should be: users with disabilities. >> >> >> >> >> >> JF >> >> >> >> On Wed, Oct 5, 2016 at 11:35 PM, lisa.seeman <lisa.seeman@zoho.com> >> wrote: >> >> I find myself agreeing with Gregg. We need WCAG to be definitive, and the >> best we can do. However that can include working harder, getting each SC as >> good as we can. I do not think we should be culling any SC for the sake of >> speed >> >> >> >> (Small note - I do not remember reaching complete consensus on issues to >> do with cognitive, but that is a side point) >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Thu, 06 Oct 2016 07:18:37 +0300 *Gregg >> Vanderheiden<gregg@raisingthefloor.org <gregg@raisingthefloor.org>>* >> wrote ---- >> >> I hope that people are listening carefully to the posts of Allen, Katie >> and others. >> >> >> >> >> >> WCAG is not an application note. It is a landmark standard with >> extremely wide application and adoption. >> >> >> >> This was possible because >> >> - it was very carefully done >> - the time was taken to carefully work out all of the SC >> - techniques and sufficiency was established for each new SC to test >> the SC with ourselves as well as with the public to be sure we knew how to >> do each one. >> - we examined each SC and ensured they were testable. >> - we did *multiple* releases of the guidelines for pubic comment and >> carefully responded to each comment - and carried on discussions with >> commenters to clear them >> - we reached complete consensus in the working group for each item >> - we took the time to create Understanding WCAG 2.0 - with >> description, rationale, examples, sufficient techniques, common failures >> where appropriate and resources for each. >> >> >> >> >> >> I am rather stunned that I see discussion of releasing a new 2.1 without >> anything like the care above being taken. I have looked at the work so >> far and it is about where we were 5 years before we completed WCAG 2.0. I >> am not saying it will take 5 more years before you are ready with any 2.1 >> but you are many years away at the pace things are currently going. (We >> had multiple people working 20-40 hours a week every week on WCAG 2.0 for >> months on end getting it to one stage or another. ) It is VERY hard. >> >> >> >> Standards like this also need to be stable so that people can create >> tools and regulations and adoption can occur. Talking about updating them >> every x years completely misunderstands the role and constraints of >> standards like this. Such a schedule would create chaos - and pretty >> much ensure that they standards will not be used -and that your goal will >> be missed. >> >> >> >> >> >> There is a famous quote that goes >> >> >> >> For *Every* Complex *Problem*, *There* Is an Answer That Is Clear, >> *Simple*, and Wrong. So almost said H.L. Mencken as part of a longer >> aphorism. The whole quote is, “Explanations exist; they have existed for >> all time; *there* is always a well-known *solution* to *every* human >> *problem* — neat, plausible, and wrong.”Dec 7, 2015 >> >> >> >> >> >> Wanting to have a strong - well thought out - adopted standard that is >> rapidly updated is a nice thought — but not possible technically, >> logistically or rationally given the time spans needed for any of the three >> (development, public review/testing, and adoption). >> >> >> >> >> >> The current timeline for 2.1 is already unrealistic. One should never >> set a date for something this complex based on when it would be good to >> ship. It should ship when it is ready — and the focus should be on WORK >> to get it done sooner. Not setting a deadline and deciding that you will >> ship whatever you have at that point. >> >> >> >> The WCAG 2.0 working group was incredibly frustrated by the time it took >> to complete WCAG 2.0. But our response to the time it was taking was to >> work harder - get out more public reviews so that we could advance it and >> find the holes — in order to get it done, and recruit and increase the time >> spent per week getting it done. >> >> >> >> The current 2.1 is not tested, not reviewed, not implemented, and not >> done yet there is a lot of talk about ship date. Until we have it >> complete and out for review - we aren't even half done. (Believe me). >> >> >> >> >> >> >> >> PLEASE - don’t listen to your angst or clammoring for something new to >> ship. Act in haste and repent at leisure. If we ship something with >> out review and incomplete - and say that we will ship another soon to >> finish it of fix it — we are just inviting people to ignore it. First >> because it will have flaws that make it easy to criticize, and second >> because we have told them not to - because there will be another soon that >> will be better and fix holes in the last. The adoption and support curve >> is 5-8 years. Why would people/agencies begin it for any version that >> will be replace by another before its get adoption. We can say that a >> 5-8 year adoption curve is too long but that I like saying 9 months is too >> long for a pregnancy. We can complain all we like - but that is what it >> takes. And there is nothing we can do about it. >> >> >> >> DO PLEASE ship regular updates to techniques. >> >> >> >> DON’T change the rules regularly or prematurely or we undo what we are >> trying to do. >> >> >> >> I too am frustrated by how long it takes. And how hard it is. But >> I can’t and won’t change desires for reality — or make the mistake of >> trying to hatch this before it is done being developed. You have wisdom >> and impatience fighting each other. Be wise. >> >> >> >> >> *gregg* >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> John Foliot >> >> Principal Accessibility Strategist >> >> Deque Systems Inc. >> >> john.foliot@deque.com >> >> >> >> Advancing the mission of digital accessibility and inclusion >> >> >> >> ------------------------------ >> >> This e-mail and any files transmitted with it may contain privileged or >> confidential information. It is solely for use by the individual for whom >> it is intended, even if addressed incorrectly. If you received this e-mail >> in error, please notify the sender; do not disclose, copy, distribute, or >> take any action in reliance on the contents of this information; and delete >> it from your system. Any other use of this e-mail is prohibited. >> >> Thank you for your compliance. >> ------------------------------ >> > >
Received on Sunday, 9 October 2016 02:59:24 UTC