Re: Coming to a decision on 2.2

I like it David — your original  that is. 

I don’t think you should introduce the word “core"
Introducing the word core just begs the question.   “which part of WCAG 2.0 is core and which part of WCAG 2.0 is not core”

but this reads and works fine:
> "Extensions may provide additional accessibility requirements over and above WCAG2, any requirements provided by an extension must also satisfy the original WCAG 2.0."



gregg

> On Feb 20, 2016, at 12:30 AM, David MacDonald <david100@sympatico.ca> wrote:
> 
> slight modification to use the word "core" to represent WCAG 2
> 
> "Extensions may provide additional accessibility requirements over and above WCAG2, any requirements provided by an extension must also satisfy the original WCAG 2.0 core."
> 
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
> GitHub <https://github.com/DavidMacDonald>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>   
>   Adapting the web to all users
>             Including those with disabilities
> 
> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>
> On Fri, Feb 19, 2016 at 6:28 PM, David MacDonald <david100@sympatico.ca <mailto:david100@sympatico.ca>> wrote:
> I think we might get more success if we don't map particular SCs in extensions to existing WCAG extensions. We just need to ensure that WCAG remains stable and is met, even when an extension enacted. How about something like this:
> 
> "Extensions may provide additional accessibility requirements over and above WCAG2, any requirements provided by an extension must also satisfy the original WCAG 2.0."
> 
> 
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902 <tel:613.235.4902>
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
> GitHub <https://github.com/DavidMacDonald>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>   
>   Adapting the web to all users
>             Including those with disabilities
> 
> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>
> 
> On Fri, Feb 19, 2016 at 1:58 PM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>> wrote:
> TL;DR
> 
>  
> 
> We should not be changing WCAG SC text for any reason, and new SC should be given new, unique numbers.
> 
>  
> 
>      *****
> 
>  
> 
> All,
> 
>  
> 
> May I suggest that the problem is here:
> 
> 
> “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.”
> 
>  
> 
> I fundamentally believe that modifying the text of an existing Success Criteria should not be contemplated, but instead that if/when a new, “stronger” or otherwise improved SC be introduced, and that it either have a “.X” numbering or a whole new SC number.
> 
>  
> 
> We already have existing precedence in WCAG 2.0 with, for example, SC 1.2.3 Audio Description or Media Alternative (Prerecorded) which is an (A) requirement, and SC 1.2.8 Media Alternative (Prerecorded) which is a (AAA) requirement. Likewise with SC 1.4.3 Contrast (Minimum) at (AA) and SC 1.4.6 Contrast (Enhanced) at (AAA).
> 
>  
> 
>  
> 
> How could this work? Using a recent example of some protracted discussion on this list, let’s look at SC 1.3.1 Info and Relationships (A), which exposed some differences of opinion and (in my belief) also exposed a gap in WCAG 2.0 today.
> 
>  
> 
> As you likely recall, that discussion was around whether or not form input labels (on screen) should be clickable. The consensus decisions (as I recall) was that, no, SC 1.3.1 does not mandate that requirement, despite lots of good reasons why it should have (notably for Low Vision users).
> 
>  
> 
> So, we could (should?) create an enhancement to SC 1.3.1 – perhaps in the LVTF - that addresses this gap. “Adding” it to WCAG could be done in one of two ways (I propose):
> 
>  
> 
> 1)      Create a SC 1.3.1.1, which would be a child of SC 1.3.1:
> 
> 1.3.1 Info and Relationships: Information, structure <https://www.w3.org/TR/WCAG20/#structuredef>, and relationships <https://www.w3.org/TR/WCAG20/#relationshipsdef> conveyed through presentation <https://www.w3.org/TR/WCAG20/#presentationdef> can be programmatically determined <https://www.w3.org/TR/WCAG20/#programmaticallydetermineddef> or are available in text. (Level A)
> 
> 
> 1.3.1.1 Actionable Relationships: Relationships <https://www.w3.org/TR/WCAG20/#relationshipsdef> conveyed through the use of <label> or aria-describedby should allow users to place tab-focus on the related element when activated. (For example, clicking on the “Name” label puts focus on the associated input field) (AA)
> 
>  
> 
> 2)      Create a new Success Criteria:
> 
> 1.3.4 Actionable Relationships: Relationships conveyed through the use of <label> or aria-describedby should allow users to place tab-focus on the related element when activated. (For example, clicking on the “Name” label puts focus on the associated input field) (AA)
> 
> 
> (Note, let’s not try and wordsmith my example here, I knocked this out quickly to serve to illustrate only)
> 
> 
> Of the two options above, my personal preference would be for option 2 (but I also think we should explore both options more fully).
> 
>  
> 
> I also wonder aloud how this would impact reporting compliance to WCAG 2.0 – does adding new SC mean we will emerge with a WCAG 2.1? Or WCAG 2.0 + LVSC (Low Vision Success Criteria), and/or WCAG 2.0 + CSC (Cognitive Success Criteria) (which leaves open the idea of “WCAG 2.0 + LVSC, CSC” etc.)?
> 
>  
> 
> As I think about those questions in tandem, I emerge with proposing that we:
> 
> 
> a)     Disallow modifications in any way to existing Success Criteria – that modifications, enhancements, etc. are assigned new SC numbers.
> 
> 
> b)     Once new Draft SC have worked their way through the W3C process, that an annual (?) or calendared update be released as WCAG 2.1 (and then follow on with 2.2, 2.3, etc. as required)
> 
> 
> c)      Conformance to newer WCAGs (i.e. a WCAG 2.1) is an all-or-nothing proposition. It’s not that we discourage anyone from achieving even 1 of say 5 new Success Criteria in a new WCAG 2.1 (I’m making up those numbers BTW), but that to be conformant to the new WCAG, *all* of the added Success Criteria be met.
> 
>  
> 
> Anyway, those are my thoughts. Pick them apart as you see fit. J
> 
>  
> 
> JF
> 
>  
> 
>   <>
> From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>] 
> Sent: Friday, February 19, 2016 9:11 AM
> To: Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>
> Cc: White, Jason J <jjwhite@ets.org <mailto:jjwhite@ets.org>>; GLWAI Guidelines WG org <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://twitter.com/awkawk>
> http://blogs.adobe.com/accessibility <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 <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/09-wai-wcag-minutes.html#item04>, https://www.w3.org/2016/02/16-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 <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 <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 <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://twitter.com/awkawk>
> http://blogs.adobe.com/accessibility <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.
> 
>  
> 
> 
>