Re: Coming to a decision on 2.2

To follow up to myself (how meta), the 2.2 text sans-modification terminology could be:

2.2 Ensure that web pages which conform to WCAG 2.0 with an extension also conform to WCAG 2.0 on its own

Extension specifications are expected to offer additional guidelines and success criteria but extensions may not weaken what is required of web content. The result of this is that when a page conforms to WCAG 2.0 with an extension, it must also conform to WCAG 2.0 if the extension is not considered in the conformance review.

Example 1

  *   An existing success criterion may change in priority from a lower level to a higher level, but not the other way around. For example, a Level A Success Criteria cannot move to Level AA.
  *   A new success criterion may be added.

-Alastair


From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Date: Tuesday, 23 February 2016 at 10:20
To: 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Coming to a decision on 2.2
Resent-From: <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Tuesday, 23 February 2016 at 10:21

Hi everyone,

I opened up my WCAG folder this morning and found this huge thread, to summarise my thoughts on the naming convention / document process:

  *   I agree with John’s wish for a living doc, but appreciate Katie’s point that it doesn’t work for some major consumers of WCAG.
  *   I agree that saying “this extra SC for low vision users” doesn’t stand much chance of being used in practice if it isn’t part of the main WCAG document.
  *   Given the constraints, I think it best if extra SC are documented by task forces, tested by the wider community, scrutinised for clashes across extensions, and then rolled into WCAG as a major update in the medium term (perhaps for the next chartering?).
  *   It would be very useful to reference WCAG 2.0 SC from the extensions, but I’m wary of 1.3.1-LV or similar. If some reference WCAG 2 and some don’t, how would the non-WCAG ones be numbered? Perhaps each SC from a task force should have it’s own numbering with a clear means of referencing the original.

On the text for 2.2, perhaps it would be best to drop the concept of modifying altogether?

In all the examples I’ve seen so far, a new SC from a task force would extend or add to WCAG2. If it cannot undermine the original SC, then how can it modify it? It isn’t modifying it, it is adding or extending it… just drop the last bullet point.

Is there an example where a new SC could modify an original one without undermining it? An example where it couldn’t just be treated as adding or extending?

-Alastair

--

Alastair Campbell

www.nomensa.com
follow us: @we_are_nomensa or me: @alastc