Re: charter update with two year cycle

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

That's right we don't. If we had shipped WCAG 2 in 2006 when we were in the
final cycle, without getting it right we would have been a colossal
failure. Those two years until 2008 enabled us to address 1200 public
comments and emerge with no formal objections and one of the most
successful standards in history. Personally, I suffered tremendously
financially during those two years of volunteering, I had plenty of
incentive to get something out there to consult on. But I'm glad I waited.

> PwD need this guidance

Let's agree not invoke shrill rhetoric at those who have a different idea
of how to do this successfully.  I think the people of this WG know where
my heart is.

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 Mon, Oct 10, 2016 at 3:05 PM, John Foliot <john.foliot@deque.com> wrote:

> 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
>