Re: Coming to a decision on 2.2

Gregg,
The requirements document states that "Extension specifications are expected to offer modifications to existing WCAG 2.0 success criteria as well as 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."

For example (and this is not anything that is expected, just a hypothetical):
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

An extension could say that what is required to satisfy the extension is to reinterpret WCAG 2.0’s 1.4.3 to read:
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.0:1, except for the following: (Level AA)

If you are meeting WCAG 2.0 by itself then you can have text that is 4.5:1, but if you are meeting the extension then you need to have text that is 4.0:1, which allows the page to meet the “at least 4.5:1” language of the original SC as well.

The extension is not changing the SC in WCAG 2.0, it is modifying the SC in the context of the extension.

This is similar to what is done in the HTML Longdesc extension.  The extension is indicating that the image element should now permit an attribute that the HTML5 specification does not allow.

All of the details regarding numbering and association with the techniques are details that do need to be figured out at some point, but I regard as more about the user experience of using the extensions rather than core requirements for the extensions.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility


From: CAE-Vanderhe <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>
Date: Friday, February 19, 2016 at 10:10
To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Cc: "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Coming to a decision on 2.2

Hmmmmmm

You can’t change a WCAG SC
and numbering your extension  SCs to have the same numbers as WCAG SCs sounds like a recipe for confusion.

I would assume that extensions would have different numbers?

If you want to move an SC - but not change it - that might be possible in an extension.

but if you have techniques for an extension — it will be very confusing to have them “satisfy SC 3.2” if there are two 3.2s
I presume you don’t want a different techniques doc.   so you will want the extension SC to be distinguishable from the WCAG SC.   So you can say ‘ this techniques is sufficient for  SC 3.2  but not for SC-XM-3.5     (or even SC-XM-3.2   or whatever)  which requires….

if you keep the same numbers and change the text you can end up with a sentence like
 " …  this would be sufficient for SC 3.2  but not for SC 3.2  if you are claiming conformance to the extension.”

(and the discussions on GL about whether it meets   SC 3.2  when there are two of them…..)   (or more if more than one extension???)

Am I missing something?    or have we just not thought about numbering SCs and how that would relate to techniques and understanding docs….

gregg

On Feb 19, 2016, at 3:31 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:

The challenge with this language is that the original bullet point is talking about changing a SC, not creating a new one.  I think that will create confusion to suggest that the extension is creating a new SC when it is just modifying an existing SC.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility


From: "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>
Date: Friday, February 19, 2016 at 07:58
To: CAE-Vanderhe <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>Y>
Cc: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Coming to a decision on 2.2

+1 to Gregg’s suggested statement.

I can live with the original as proposed at the start of this thread, but Gregg’s is excellent.


From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
Sent: Thursday, February 18, 2016 6:41 PM
To: Andrew Kirkpatrick
Cc: GLWAI Guidelines WG org
Subject: Re: Coming to a decision on 2.2

how about


  *   A new success criterion may cover the same topic as a WCAG 2.0 success criterion, but passing the new SC must also satisfy the WCAG 2.0 success criterion.




gregg

On Feb 18, 2016, at 11:57 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:

As a result of discussion on the WCAG call (https://www.w3.org/2016/02/09-wai-wcag-minutes.html#item04, https://www.w3.org/2016/02/16-wai-wcag-minutes.html#item04), on this thread (https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0133.html) and in a survey (https://www.w3.org/2002/09/wbs/35422/20160209/results#xq2), we do not have a clear consensus on the wording for the third bullet in 2.2 of the requirements document (https://www.w3.org/TR/wcag2-ext-req/#ensure-that-web-pages-which-conform-to-wcag-2.0-with-an-extension-also-conform-to-wcag-2.0-on-its-own).

The entire text of 2.2 reads as follows:
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 modifications to existing WCAG 2.0 success criteria as well as 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.
  *   Existing success criterion may be modified, but the resulting change must still satisfy WCAG 2.0 success criteria.

We need some suggestions.  The WCAG’ers on the call believe that the 3rd bullet isn’t quite right and we don’t have agreement on the alternatives.  We want to clearly convey that the extensions may alter the text of a success criteria, but that in doing so a web page that passes the version of the success criteria in the extension must also pass the version of the success criteria in WCAG 2.0.

Any suggestions for language?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility



________________________________
This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.