Re: Coming to a decision on 2.2

+1. I think adding "Core" to WCAG may creates such a confusion.

Thanks,
Srini

Best regards,

*Srinivasu Chakravarthula*
Sr. Accessibility Consultant
Deque University <http://dequeuniversity.com> | Deque <http://deque.com>


On Mon, Feb 22, 2016 at 3:24 PM, Neil Milliken <Neil.Milliken@bbc.co.uk>
wrote:

> To define elements as core sends a signal that the rest is OK to ignore.
> Let's keep it simple especially when it comes to COGA.
> ------------------------------
> *From:* Andrew Kirkpatrick [akirkpat@adobe.com]
> *Sent:* 22 February 2016 01:40
> *To:* Katie Haritos-Shea; CAE-Vanderhe
> *Cc:* John Foliot; David MacDonald; Jason J White; GLWAI Guidelines WG org
>
> *Subject:* Re: Coming to a decision on 2.2
>
> +1 to that. Are we done yet?...:-)
>
> Ha!  We all wish!
>
> I think the main issue with this language is that is doesn’t seem like it
> says anything new.  The language of 2.2 is:
>
> Ensure that web pages which conform to WCAG 2.0 with an extension also
> conform to WCAG 2.0 on its own.
>
> And the suggestion is:
>
> Extensions may provide additional accessibility requirements over and
> above WCAG2, any requirements provided by an extension must also satisfy
> the original WCAG 2.0.
>
> The text that we are trying to address here is the line in the example
> which addresses the  points about changing the priority level of an SC,
> adding a SC, and this last one is speaking to the changing of existing SC
> text.  This is something that the group wanted to allow, so we are trying
> to offer an example that helps make this clear.  I don’t think that this
> text accomplishes that.
>
> AWK
>
>
>
> On Feb 20, 2016 12:29 AM, "Gregg Vanderheiden RTF" <
> gregg@raisingthefloor.org> wrote:
>
>> 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
>>
>>
>> *Can**Adapt**Solutions Inc.*
>> Tel:  613.235.4902
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>> 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>
>> 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
>>>
>>>
>>> *Can**Adapt**Solutions Inc.*
>>> Tel:  613.235.4902
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>> 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>
>>> 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]
>>>> *Sent:* Friday, February 19, 2016 9:11 AM
>>>> *To:* Andrew Kirkpatrick <akirkpat@adobe.com>
>>>> *Cc:* White, Jason J <jjwhite@ets.org>; GLWAI Guidelines WG org <
>>>> 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>
>>>> 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
>>>>
>>>> http://twitter.com/awkawk
>>>>
>>>> http://blogs.adobe.com/accessibility
>>>>
>>>>
>>>>
>>>> *From: *"White, Jason J" <jjwhite@ets.org>
>>>> *Date: *Friday, February 19, 2016 at 07:58
>>>> *To: *CAE-Vanderhe <gregg@raisingthefloor.org>, Andrew Kirkpatrick <
>>>> akirkpat@adobe.comY>
>>>> *Cc: *WCAG <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
>>>> <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>
>>>> 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
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>