Re: charter update with two year cycle

David wrote:

> "we won't be done creating SCs from our current gap analysis during the
charter period but we're going to ship WCAG 2.1 anyway, and then ship again
when we get it done."

This is *EXACTLY* the problem... the second part of your statement has no
specific timeline to it, and this is what the AC is pushing back hard on
from *all* Working Groups at the W3C, not just ours.

When, *exactly*, will "...when we get it done" be, they will ask?

5 years later? 7 years? 10 years? "We don't know"?

For many of the active AC membership, that is unacceptable. Articulating a
"Vision Statement" where we envision "shipping again" in 2-year cycles does
not bind us to that in this current Charter beyond "intent", but it does
indicate that we intend to keep working on the backlog of SC that will
continue to exist after the 2.1 release, and if we're still not finished 2
years after that we'll ship the next batch that is ready ready then, and
hopefully continue marching forward under yet another renewed Charter. It
also leaves open the door that we *may* also ship a 2.3 after that
(assuming that the Silver Project is still being discussed: conversely that
next "ship date" of 2022 might very well be "Silver", which comes chugging
along at the 2-year interval gap we've established as our new norm).

It's a question of establishing visionary milestones beyond the current
charter, versus some vague hand-wavy "we don't know when, but when they are
ready we'll ship it" statement. We may have gotten away with that in 2002,
or even 2008, but times have changed at the W3C, and process too, and
whether you agree with that or not, that is the new reality today.

And while some keep arguing for a "go-slower" approach, you've not
explained the benefit of that approach, only to say that it's a departure
from what this WG thought was the best path forward 8 years ago.

Sure, fine, it is. But can you please explain why it's "bad"? What do we
lose by adding the backlog of ~50 newly proposed Success Criteria - not
Techniques or Understandings but actual new SC - on a regular schedule as
they are ready? You appear to be fine with the first batch shipping in the
2.1 time-frame, but for any and all SC that miss that cut-off, you seem to
be advocating for delaying *everything* until they are all completed. Why?
What benefit do we accrue from that?


> The WCAG 2 model (Principles, Guidelines, Success Criteria, & Techniques)
was never intended to be on a 2 year cycle. It was created to *overcome*
the need for a 2 year cycle to stay relevant.

And yet, here we are, 8 years later and while WCAG has shown to be an
extremely resilient W3C Recommendation, we have gaps - big ones, 50 new
proposed Success Criteria worth of gaps today - and working under a model
that may have made sense in 2002 (when the W3C was committed to working on
XHTML 2, and technologies such as mobile platforms and Responsive Web
Design weren't even on our radar) does not seem today to be 100% completely
tenable. It also certainly does not help to keep WCAG relevant to anyone
beyond legislators: developers and PwD need this guidance and techniques
now, and not in some mystical time "...when we get it done".

Decade-long gaps between updated guidance may work in the legislative
world, but in the world of technology in 2016 that is not only laughable,
it is ludicrous, and we've already heard through various channels that the
member-funded W3C will quite likely not look kindly on this Working Group
operating in a bubble outside the reality of all the other Working Groups
at the W3C. This is the candid advice, BTW, that we have received from
established and well-versed AC and AB representatives at the W3C, along
with some W3C staffers, and ignoring their advice and suggestions is to do
so at our peril.


> The two year cycle model is very old fashioned...

Actually David, the "ship it all when it's completed" model you are
advocating for is the old-fashioned model.

The current model, the one that the W3C management and AC are pushing for,
is to ship early, and ship often. I don't understand the fear and
resistance to shipping batches of Success Criteria incrementally and
bi-annually as we process the ~50 SC we have today: you haven't explained
the harm of that, or the benefit of why this Working Group should continue
to use the older waterfall model you are advocating for, except to say that
wasn't the "plan" 8 to 14 years ago.

(And at the risk of appearing to slam the hard-working folks at the US
Access board, the Section 508 refresh debacle is further proof that the
all-or-nothing approach is hurtful to our primary constituents - People
with Disabilities.)

JF


On Sat, Oct 8, 2016 at 6:34 PM, David MacDonald <david100@sympatico.ca>
wrote:

> >we aren't "committing" to anything beyond the deliverables in the draft
> charter
>
> I believe the word "commitment" is your word from the TPAC face to face as
> you presented it to the group and privately. You wanted the group to be
> "committed" and held accountable to do this, that is how you explained it
> to us.
>
> >The 2-year cycle language is there to express *INTENT*
>
> I don't think the current model should be automatically given the "INTENT"
> to do something it wasn't INTENDED to do. The WCAG 2 model (Principles,
> Guidelines, Success Criteria, & Techniques) was never intended to be on a 2
> year cycle. It was created to *overcome* the need for a 2 year cycle to
> stay relevant. It was created to provide stable testable criteria without
> being limited by the technical changes that come and go every year. The two
> year cycle model is very old fashioned... it's WCAG 1. I'm not saying
> Silver won't figure this out balance of "relevance" and "stability" in a
> new and better way than WCAG 2, but a two year cycle is not the WCAG 2
> model.
>
> Now if you mean...  "we won't be done creating SCs from our current gap
> analysis during the charter period but we're going to ship WCAG 2.1 anyway,
> and then ship again when we get it done." Then let's say that in the
> Charter. That's not a 2 year cycle, that's a late delivery with an interim
> stop gap release, which is a different thing.
>
>
>
> 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 Sat, Oct 8, 2016 at 12:42 PM, John Foliot <john.foliot@deque.com>
> wrote:
>
>> ​​Gregg wrote:
>>
>> > Neither
>> ​>​
>> ​> We are not regulators and don’t create regulations.
>> ​> ​
>> What we are creating are not technical standards.
>> ​>​
>> ​> We are working on voluntary GUIDELINES - that may be adopted by
>> regulations - or not.    In fact they may be used in many different ways.
>>
>> Thanks Gregg, that's exactly the point: we are working on *voluntary*
>> Guidelines, and this working group needs to keep doing that. At some point,
>> regulators, commercial companies, even governmental organizations, will
>> take up and use our Guidelines, either because they are mandated to do so,
>> or because they choose to do so because they are smart (<grin>): They
>> recognize all of the benefits we've been telling them they get when they
>> apply our guidelines to their content. Yes, that includes ensuring content
>> is accessible to PwD, but they also get the SEO benefits, and the increased
>> ROI that inclusive design brings, and all the other "Fireman" reasons we
>> bring to the table (and not just the "Cop" ones...)
>>
>> Which then begs the question: do we wait until we've processed *all* the
>> new proposed SC in one big batch, or do we release them piece-meal as they
>> are ready, so that those new *voluntary* (standardized) Guidelines can be
>> voluntarily taken up with a high level of assurance by those entities that
>> *want* to do so?
>>
>> Clearly, it is obvious that is how *I* feel, and (I believe) many others
>> do as well: ship what's ready against a well known public schedule, and
>> keep working on the rest. By establishing a cadence of regular updates
>> every 2 years, we establish a pattern that stakeholders can work with,
>> around, or ignore, as they choose: but we keep shipping them every 2 years
>> as they are "ready" - in batches, and on schedule.
>>
>> Meanwhile, David wrote:
>>
>> > it seems that in the case of committing to a 2 year cycle in the
>> Charter,
>>
>> David, I think right there, I've identified a possible communication
>> issue: we aren't "committing" to anything beyond the deliverables in the
>> draft charter (https://www.w3.org/2016/09/draft-wcag-charter#normative
>> ) which covers a 2 or 3 year timespan. Specifically, we would be
>> committing to:
>>
>>    1. Releasing WCAG 2.1 (and in this Charter's timeline *ONLY* 2.1 -
>>    work on 2.2 would be a normative deliverable in the subsequent Charter)
>>    2. Accessibility Conformance Testing Framework 1.0
>>    3. FPWD of "Silver" (this is still a TBD, but I believe we should get
>>    this into the Draft as well)
>>
>> That's it, nothing more.
>>
>> The 2-year cycle language is there to express *INTENT*, because we know
>> that this effort (whether completing Silver, or continuing to add SC that
>> are coming from the TFs now, and from other groups in the future) will take
>> more than the timeframe of the current charter (2 or 3 years). It's part of
>> our plan and thinking for *AFTER* this Charter we are working on now
>> lapses; we're saying that we recognize that accessibility guidance will
>> continue to evolve, as our industry and technologies do, and that we plan
>> on avoiding getting into the kind of "trap" we are in now, with a dated (if
>> still robust) Guideline that has huge gaps to fill today, and also dealing
>> with a significant backlog. Providing this kind of "Vision Statement" was
>> recommended to some of us at the TPAC meetings, and providing that kind of
>> Vision Statement in no way locks us into that pattern, but it does
>> recognize we need to operate differently, more adroitly (agile?), and that
>> we will, as a perennial Working Group, continue to provide this type of
>> Guidance both short and long-term.
>>
>> I think that point is critical as well: The traditional W3C Working Group
>> process sees most WG's produce a spec while in Charter, and then the WG
>> "disappears". We've seen that with the HTML5 WG (it is gone, morphed into
>> the Web Apps WG), and closer to home the UAAG WG and ATAG WG have also been
>> wrapped up. But we don't see that happening (God forbid) to this WG, so it
>> is helpful to signal to the larger W3C our intent.
>>
>> Finally, Bruce wrote:
>>
>> > I  think a two year cycles is very challenged to find a sweet spot.
>> Imagine 2.2 comes out has 20+ new SC.  Or imagine 2.2 comes out and has
>> exactly one new SC, because we are committed to being boxed by the calendar
>> -- since that is part of agile.  Either way, I think people's reaction will
>> be like, "Thanks, I will wait for 3.0."
>>
>> Two thoughts: first, given the complexity of producing robust new Success
>> Criteria (and all the other attendant requirements around that, like
>> Understanding documents, and Techniques) I personally don't think we'll
>> ever get to batches of 20 per release (but maybe I'm wrong - we don't know
>> yet), but even if we are down to batches of 5 or 6, why is that a problem?
>> And if, down the road, we do arrive at a point where we're only releasing
>> one new SC at a cycle, either we're an awesome group that have covered
>> everything in a very short timeframe, or technology has decided to stop -
>> Moore's Law has burned out. (I don't really expect either of those
>> scenarios myself however).
>>
>> Meanwhile,  if a company or org *voluntarily* decides to wait for 3.0,
>> then... wait for 3.0.
>>
>> However, others may in fact choose to voluntarily take up the new SC in a
>> 2.1, or a 2.2, and even for those organizations who will wait to mandate a
>> 3.0 until it is ready, the newly minted dot-X SC could always be taken up
>> as "Best Practices" - in fact I suspect that this will likely be the
>> majority position for many organizations in the early days, especially
>> immediately after the release of 2.1. That's not necessarily a bad thing
>> BTW, but again, those orgs would be working with 'standardized' and
>> 'vetted' requirements that will "someday" be the actual requirements in
>> their world, so perhaps they (the organizations contemplating what to do)
>> will "future-proof" themselves by voluntarily taking up the new SC now. I
>> can't see any downside here.
>>
>> > I would like to let the group know that my management has quelled my
>> personal anxiety about the charter mentioning 2.1.
>> >
>> > So no, talking about WCAG 2.1 does not have any potential to disrupt
>> the Section 508 process.
>>
>> I'm very glad to hear this, and I hope you aren't "Freaking Out" any
>> longer. My offer of good scotch however remains, and I hope we can follow
>> through on that in the near future.
>>
>> Cheers!
>>
>> JF
>>
>>
>>
>> On Fri, Oct 7, 2016 at 3:14 PM, Gregg Vanderheiden <
>> gregg@raisingthefloor.org> wrote:
>>
>>>
>>> On Oct 7, 2016, at 3:55 PM, John Foliot <john.foliot@deque.com> wrote:
>>>
>>> Which raises a fundamental question: is this group working on a
>>> regulatory standard or a technical standard?
>>>
>>>
>>> Neither
>>>
>>> We are not regulators and don’t create regulations.
>>> What we are creating are not technical standards.
>>>
>>> We are working on voluntary GUIDELINES - that may be adopted by
>>> regulations - or not.    In fact they may be used in many different ways.
>>>
>>> G
>>>
>>>
>>>
>>
>>
>> --
>> John Foliot
>> Principal Accessibility Strategist
>> Deque Systems Inc.
>> john.foliot@deque.com
>>
>> Advancing the mission of digital accessibility and inclusion
>>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion