Re: charter update with two year cycle

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