RE: charter update with two year cycle

+1 to David’s comments (quoted below).

From: David MacDonald []
Sent: Thursday, October 6, 2016 7:03 AM
To: GLWAI Guidelines WG 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.

David MacDonald

CanAdapt Solutions Inc.
Tel:  613.235.4902



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Thu, Oct 6, 2016 at 2:46 AM, John Foliot <<>> 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
" SC in a 2 year period until the balance of the SC are
. That serves nobody in any effective
​ or productive​
​ 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
the discussion around
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,
​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.
​also ​
have a lon
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


It is
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
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​ "
​(who) ​
​ (WCAG)​
to improve access for users

Let's also not forget who the real primary beneficiaries of our efforts should be: users with disabilities.


On Wed, Oct 5, 2016 at 11:35 PM, lisa.seeman <<>> 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<>, Twitter<>

---- On Thu, 06 Oct 2016 07:18:37 +0300 Gregg Vanderheiden<<>> 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.


John Foliot
Principal Accessibility Strategist
Deque Systems Inc.<>

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 Thursday, 6 October 2016 12:34:51 UTC