Re: Process for WCAG 3.0 document updates

An extra remark about "*Placeholders*" and possible consequences:

Rachael wrote: "Only placeholders and the highest levels of maturity be
moved to working draft:"
Wilco wrote: "I think getting consensus about placeholder and exploratory
content is a bit too heavy-handed."

The intent for this approach seems fine and I agree, but what is a
placeholder in this case?

Take for example the "Placeholder Guidelines":
https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.20nok4tfj7v5


They are not written as...

- Guideline placeholder 1
- Guideline placeholder 2
- Guideline placeholder 3
- etc.

... but are already pretty prescriptive and already steer in a certain
direction for how they might look like (and groups with the same name
working on the guideline).
As it is already steering sub-groups to a guideline structure this might
not leave open other approaches based on other ideas / principles, like
(just some ideas) ...:

-------
*POUR 2.0 extended POUR version with additions, like:*

   - Personalisation
   - Distractions & Inflictions
   - Discoverability
   - etc.

-------
*Human Support Options, like:*

   - Personalization
   - Variations
   - Alternatives
   - Help
   - Modalities Independent
   - Privacy

-------
*Feature / Task / Component, like:*

   - Navigate
   - Meaning
   - Distractions
   - Risk
   - Alerts
   - Discover
   - Errors
   - Forms
   - Structure
   - Authentication
   - Editorial Content
   - (Multi) Media
   - Graphics
   - Help

-------
*FAST checklist based, like: *

   - visual rendering
   - control over color
   - accept user input
   - user interaction features
   - document semantics
   - time-based visual media audio
   - time limits
   - text content
   - objects that don't have an inherent text representation fallback
   mechanisms
   - visual graphics internationalization
   - accessible alternative features content directly for end-users
   - API
   - transmission protocol

-------

For this kind of "placeholders" my best guess is it would be more
productive to first do an abstract exercise on structures aiming at a
certain direction instead of publishing as "placeholder'.

We might add too much prescriptive / example placeholders  just because we
need no consensus for them and at the same time already hinting to a
direction.

If we want guidance to fit a structure without discussion on where it
should end up we might want to try to prevent this as much as possible.

Examples of this is for instance:

1. *Contrast* => is this a Guideline? Or just / only one of many Outcomes
for a Guideline?
When a guideline is "Users can perceive content" it might just be one of
many outcomes to perceive content.

2. *Headings* => is this a Guideline? Or just / only one of many Methods
for a Outcome? And if so, under which guideline?
When the guideline is "Headings" but there are alternative ways to provide
solutions besides heading, will we have conflicts in what we think is
needed?
- Are the heading used for navigation? Is there already a guideline
"Navigation"? where do they end up? (skiplinks to Main as alternative?)
- Are the headings used for Structure, do we have a guideline structure?
Are there alternative for creating the structure (like landmarks)?
- Are they there for visual identification of blocks of content? Can this
be done by labels and grouping?
In other words, will we have structure? navigation? Grouping? Visual
identification, and where does this leave headings?

Putting them all in a 'placeholder guideline structure' might make it
confusing.

3. *Instruction* => Same here... is this part of error prevention? Or a
Help Guideline? Or a "Instruction guideline" already covering error
prevention and help?

Mixing and matching them all together and publishing as a "placeholder"
this way might not be the best idea or at least we can discuss this or have
a clear definition on what conditions a placeholder have.

POSSIBLE SOLUTION:
Taking this example of the "placeholder guidelines" which in its intent is
a good one I agree with, I do not only have concerns but also a possible
solution.
My best guess for the problem as mentioned above would be to provide more
abstract multiple proposals for possible placeholder guidelines.
On top of that work out more strict:

   - What is a Guideline, how to write them
   - What is an Outcome, how to write them
   - What is a Method, how to write them

This will prevent part of the challenge deciding how a possible placeholder
structure looks like and at the same time prevent Outcomes or Methods
becoming the guideline themselves.

Cheers,
Jake










Op ma 18 okt. 2021 om 01:09 schreef Alastair Campbell <acampbell@nomensa.com
>:

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