Re: Coming to a decision on 2.2

+1 to that. Are we done yet?...:-)

Katie Haritos-Shea
703-371-5545
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.
>>>
>>>
>>>
>>
>>
>
>