Re: Straw man list for WCAG.NEXT, another proposal...

>>I've played pretty much every role in produc W3C Recommendations over the
last 2 decades.

Charles, you have been at the heart of the W3C process for year and have
been involved in many of the standards... Personally I'd love to have you
more involved in WCAG. You have a lot to offer... we miss you :)

The difference between WCAG and every other standard you and I have worked
on is the extensive legal framework hanging off it... there is no other
standard you've listed that has the weight of so many laws and landmark
legal judgements depending on it...

We have a techniques cycle every six months, because that doesn't have the
same legal weight. Webmasters don't care about the SC's, they care about
techniques which we have on a regular shipping cycle. Policy and lawmakers
care about the SCs.

Anyway, maybe I can amend model 5 to say something like... we'll ship no
later than December 2017, or we'll fall back to the interim multi stage
model...

In other words, we're going to try really hard to have those success
criteria from COGA and Low Vision, and we're willing to delay the .x
release 6 months or so for them to catch up, but if not, We'll ship the
mobile, and anything the other task forces have made that is ready.



On Sat, Apr 9, 2016 at 11:31 AM, Chaals McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Sat, 09 Apr 2016 01:50:07 +0200, White, Jason J <jjwhite@ets.org>
> wrote:
>
> From: David MacDonald [mailto:david@can-adapt.com]
>>
>> ... if we're not ready to incorporate all the task force work then lets
>>> wait to release the next version we are.
>>> Currently there is *no* model that says we will have one important 2.x
>>> release that incorporates *all* the task force work...
>>>
>>
>> I think this is the most realistic model, and very similar to what I was
>> proposing in having a single extension document. I’ve actually been through
>> the experience (once only) of taking a document all the way to W3C
>> Recommendation. It was WCAG 1.0, and I was a working group participant at
>> the time.
>>
>> I would like to back up everything that Gregg Vanderheiden says, in his
>> wise words of advice, about what is involved in achieving it – not to
>> discourage anyone, but to point out how complex an undertaking it is. Gregg
>> has worked through the process at least twice, and as Co-Chair on both
>> occasions, an achievement which is deserving of an award in my opinion.
>>
>> Expect controversy, potentially large numbers of comments, and schedules
>> that can so easily slip… significantly.
>>
>> If you want a current example, have a look at what is happening today in
>> ARIA 1.1 in terms of its planned completion schedule; and ARIA has been
>> progressing according to schedule to a much greater extent than certain
>> other specifications have done.
>>
>
> I've played pretty much every role in produc W3C Recommendations over the
> last 2 decades. As chair I've shipped a number, as editor both from start
> to finish and by taking the role for a while, as a Working Group
> participant, as the AC rep for the primary drivers of a set of specs, even
> as AC rep for people opposed to the work. I've also played pretty much
> every role in trying to make Recommendations that ended up in failure.
>
> I think the ARIA 1.1 example is a good one to look at. Schedules do slip,
> and things turn out to be harder than we thought. Nevertheless I think it
> is likely that ARIA 1.1 will ship, within some reasonable approximation of
> its timetable.
>
> But in particular with making revisions, my experience is that smaller is
> easier. If we work towards a major rewrite, there is a lot of pressure to
> get everything in, and right, before we ship. This was how e.g. CSS 2.1,
> SVG 1.2, WCAG 2.0 and HTML 5 all took so many years. HTML 5 would quite
> possibly still not be finished if we hadn't decided a few years ago to work
> on a date-driven process of adding incremental updates to HTML as they are
> ready.
>
> Having a clear sense that we have a production cycle, that things not
> ready for this round will be included in the next which is a year or so
> away rather than a decade, generally reduces the pressure to hold up
> everything while one more thing gets finished - a trap, since then one
> other thing is almost ready and should be included.
>
> "Shipping is a feature". And setting the goals in a way that provides
> pressure to get work done to a high enough quality for inclusion now,
> rather than to motivate delaying releases, is a very helpful way to achieve
> it.
>
> cheers
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>
>