Re: Coming to a decision on 2.2

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.
>>
>>
>>
>
>