Re: charter update with two year cycle

Hi all,

Quick off topic request for everyone, can you try to edit your mails down
and not rehash things.

Unfortunately I didn't get much response to my previous e-mail. So, I'll
answer my own questions :P

*What can we do for organisations that can't keep up with a 2 year update
cycle for WCAG 2? *What I suggested to John is that we provide
documentation for using WCAG 2.x in legislation. If we communicate how
(government) organisations should work with WCAG in their policies, we work
with them to find out what concerns are and make sure there are answers
readily available for them, instead of letting each different legislator
figure it out for themselves, they'll probably have a much easier time with
a 2 year cycle then they would if we didn't.

*Can we make new criteria available as they become available, without
having to do a release every 2 years? *Of course we can! We could set up a
system where success criteria get published as notes once they are stable.
They can be used the moment they are ready, without having to update WCAG.
People looking to anticipate on what's coming up can do so, without us
releasing a new version of WCAG every 2 years. You could release every 4 or
5 years, and you can still make new criteria available for organisations
interested in using them.

Hope this helps!

Wilco



On Mon, Oct 10, 2016 at 9: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
>



-- 
*Wilco Fiers* - Senior Accessibility Engineer