RE: Process for WCAG 3.0 document updates

Hi Everyone,

This is my (chair-hat off) thoughts prompted by Gregg & Andrews comments. See Rachael's email from Friday for the immediate suggested changes to the proposal.

At a high level I think there are a couple of factors that might lead us to a different approach to WCAG 3.0.


  1.  There are more moving parts. Changes to conformance, scoring, testing, or the structure of the guidelines have ripple impacts across the docs.
I'm certainly not saying WCAG 2.0 development was in any way easy, but thanks to that success the scope of WCAG 3.0 is wider and trying to do more. There are lots of sub-groups working in parallel, it's going to be hard to keep track across that work if it is not centralised with clear status labels.

  2.  The dynamics of ongoing public review. In WCAG 2.0 comments went into a bug-tracker (a black hole from an external point of view), until they were dealt with and a reply issued. There was a big wave of comments, then an updated version and publication. Whether we like it or not, now people comment in public, other people can join in, and it is a rolling & ongoing thing.


Andrew wrote:
> I believe that the risk of including content that hasn't reached consensus into the editor's draft and the working draft is risky and we will wind up spending more time responding to comments and critiques for unvetted content than we can afford.

Indeed, but I think we need to adapt to that rather than avoid it.

Perhaps we could restrict comments to the levels that appear at working draft? That would mean any comment on something marked less than "Maturing" could have a default reply of something like:
"Thanks but... This section does not have consensus of the group and may not appear in the next draft document. We are not responding to comments on this area yet. If you'd like to take part please..."

We could even put that in the editors draft for things marked 'exploratory'.


> The WG may want to remove it but this is strongly opposed by a few individuals and at the same time keeping it in is strongly opposed by just as many or more.

I agree this is an important point that needs thinking through. Since 2.0 the default has been "agreement to add" and significant objections meant status quo. And once something is in, we can't take it out (at least partly due to backwards compatibility).
I don't know how guidelines were included/excluded before the 1st working draft?


> there are many people on the WG with decades of experience and getting consensus across the WG is essential prior to expecting that a less-engaged public will provide additional scrutiny.

Note that a key request was for targeted reviews rather than the general public. Particular people with (e.g. legal) expertise could be asked to review an early draft when it includes something relevent to them.

Since Friday several ideas have been suggested which I think might help get us there:


  *   A note about current status & known issues could be prepended to each section.
  *   Transparency & notifications about new content.
  *   The working group understanding they need to be less strict about the lower levels.
  *   An explicit understanding that things can be removed prior to CR if issues are not resolved.

Also consider that we need to have a reasonable amount of guideline content in order to work through: The guideline/outcome structure, protocols, 3rd party content, conformance, sampling, reporting, accessibility supported, alternative versions, maturity model etc etc etc.

Once we have settled most of these over-arching aspects we should also be able to define criteria for guideline inclusion. Until then, I think we should not be particularly strict about guideline inclusion. After that, I think all guideline content should then be up for a round of reviews and refinement, and dropping them needs to be an option.

Historically I've noticed a lot of comments/questions on pre-draft materials (e.g. wiki pages) that people in the group were working on prior to WCAG 2.0 / 2.1 publications. At least with the proposed approach it could be in one place (2 documents) and labelled appropriately.

Kind regards,

-Alastair

--

@alastc / www.nomensa.com<http://www.nomensa.com>