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
>