Re[2]: Coming to a decision on 2.2

Hi Alan,

>I am confused as a requirements management lead for many years, how can 
>something be an additional requirement “over and above” and yet still 
>satisfy the original? The two cannot co-exist.
>
Yes, they can. I understand that this stuff can be confusing btw.. but 
the idea is that the extensions will _extend_ the scope of the original. 
Additions to SC 1.4.3 are a good example whereby an Low Vision extension 
may have stronger requirements for colour luminosity than the original - 
so if the conformance claim is made against WCAG SC 1.4.3 + LVTF 
(extension 'X' with stronger requirements) both are satisfied if the UI 
that the claim is being made against has the stronger colour 
luminosity/ratio requirements.

HTH

Josh

>
>
>
>Also, has anyone taken these new extension requirements and seen if in 
>fact they actually can be applied in such a way?
>
>
>
>I may be wrong.
>
>
>
>Alan
>
>
>
>
>
>Sent from Mail for Windows 10
>
>
>
>From: Mike Elledge
>Sent: Monday, February 22, 2016 2:56 PM
>To: John Foliot; 'Katie Haritos-Shea'
>Cc: 'David MacDonald'; 'CAE-Vanderhe'; 'Jason J White'; 'Sailesh 
>Panchang'; 'Andrew Kirkpatrick'; 'GLWAI Guidelines WG org'
>Subject: Re: Coming to a decision on 2.2
>
>
>
>Associating extensions with existing success criteria would provide 
>context to evaluators and developers, so I'm all for it.
>
>
>
>
>I'd also suggest simplifying David's suggestion to the following:
>
>
>
>
>
>
>"Extensions may provide additional accessibility requirements over and 
>above WCAG2, but in any case must satisfy the original WCAG 2.0."
>
>Thoughts?
>
>Mike
>
>
>
>On Monday, February 22, 2016 2:23 PM, John Foliot 
><john.foliot@deque.com> wrote:
>
>
>
>Hi Katie,
>
>
>
>My concern is making new Success Criteria (whether brand new, or 
>modifying a new SC to make it ‘stronger’) user-group specific. It 
>perpetuates a ghetto mentality that runs counter to our bigger message 
>(aka Universal Design).
>
>
>
>The fact that a TF that is looking specifically at issues related to 
>Low Vision users (or Cognitive users, or Mobile users – which sort of 
>is everybody) helps bring focus to those types of needs, and ensures 
>that the next-gen WCAG addresses shortcomings that specifically affects 
>that group, but I will suggest that increasing the contrast 
>requirements [sic] will benefit not only LV users, but perhaps Mobile 
>users and Seniors as well, so making it a “Low Vision” Success Criteria 
>in name feels (to me) wrong.
>
>
>
>I had previously suggested an additional “dot-number” scheme (such as 
>your suggested 1.4.3.1) and that may be one way forward, although 
>again, looking at how we’ve addressed other “strengthening” 
>requirements previously (for example 1.4.3 versus 1.4.6) suggests that 
>creating new Success Criteria (still grouped under one of the four main 
>‘headings’ of P, O, U, or R) is more ‘flexible’ and/or consistent 
>moving forward.
>
>
>
>If I were King of the World (which sadly I’m not) I’d look to author 
>new Success Criteria across all of the current Task Forces, and once a 
>specific SC meets group approval, we roll it into a “Living Document” 
>type scheme, and that we’d articulate specific Milestone dates, at 
>which point all “approved” new SC, along with the current WCAG 2.0 
>becomes WCAG 2.1 [sic] – fully realizing that we can’t actually do that 
>today with the current WCAG WG Charter today (although there is some 
>suggestion that we may be able to do a WCAG 2.0-2016, which would get 
>around some of the concerns about a living document WCAG, although it 
>seems to me to be a silly distinction in many ways).
>
>
>
>Perhaps we need to look at addressing that problem at a higher level?
>
>
>
>JF
>
>
>
>From: Katie Haritos-Shea [mailto:ryladog@gmail.com]
>Sent: Monday, February 22, 2016 12:53 PM
>To: John Foliot <john.foliot@deque.com>
>Cc: David MacDonald <david100@sympatico.ca>; CAE-Vanderhe 
><gregg@raisingthefloor.org>; Jason J White <jjwhite@ets.org>; Sailesh 
>Panchang <sailesh.panchang@deque.com>; Andrew Kirkpatrick 
><akirkpat@adobe.com>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
>Subject: RE: Coming to a decision on 2.2
>
>
>
>I can see and suggest relating any new SC to a specific WCAG 2 SC  
>number when it makes sense to do so - such as a new level of Minimum 
>Contrast from LV such as; 1.4.3 + LV -- or -- 1.4.3.1LV. In the 
>circumstances where there is not relevant existing WCAG 2 SC and a new 
>one needs to be added such as; (for say a touch target size) place it 
>under the relevant Guideline (which I'll pretend a new GL '2.5 Make 
>content East to Operate' (for example only) add a new SC 2.5.1-Mobile: 
>Touch Target (Minimum).
>
>In any case, developers and tester will be using multiple checklists.
>
>I am not married to this suggestion. It is just an idea.
>
>My two cents.
>
>Katie Haritos-Shea
>703-371-5545
>
>On Feb 22, 2016 10:10 AM, "John Foliot" <john.foliot@deque.com> wrote:
>
>>+1 (again).
>>
>>I strongly feel that adding new SC, as opposed to making edits to 
>>existing SC is the right way forward, even if (in practice) a new SC 
>>modifies/strengthens an existing SC. We’ve done that already (as I 
>>noted previously).
>>
>>
>>
>>Additionally, I worry about speaking in terms of WCAG 2.0 + [user 
>>group] style conformance reporting, as once we start getting new 
>>success criteria from different Task Forces this will spin into a 
>>confusing and onerous task of reporting conformance. While I recognize 
>>that the current Charter does not allow for any other means of 
>>reporting the addition of new Success Criteria (such as perhaps a WCAG 
>>2.1), I’ll stick my neck out and say that we collectively need to 
>>address this short-coming sooner rather than later.
>>
>>
>>
>>JF
>>
>>
>>
>>From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org]
>>Sent: Monday, February 22, 2016 12:00 PM
>>To: Sailesh Panchang <sailesh.panchang@deque.com>
>>Cc: Andrew Kirkpatrick <akirkpat@adobe.com>; Katie Haritos-Shea 
>><ryladog@gmail.com>; John Foliot <john.foliot@deque.com>; David 
>>MacDonald <david100@sympatico.ca>; Jason J White <jjwhite@ets.org>; 
>>GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
>>Subject: Re: Coming to a decision on 2.2
>>
>>
>>
>>>should not the  statement, "Extension specifications are expected to
>>>offer modifications to existing WCAG 2.0 success criteria  ..." be
>>>worded differently to convey what is intended?
>>>
>>
>>
>>Interesting.
>>
>>
>>
>>You might have put your finger on it.
>>
>>
>>
>>when I read
>>
>>>"Extension specifications are expected to offer modifications to 
>>>existing WCAG 2.0 success criteria  ..." be
>>>worded differently to convey what is intended?
>>>
>>
>>
>>
>>
>>I read it as   “offer modifications to the existing set of WCAG 2.0 
>>success criteria” meaning that it would extend the set — not edit the 
>>SC.
>>
>>
>>
>>
>>
>>I think that editing the SC or re-using those number will create great 
>>confusion.
>>
>>
>>
>>instead I suggest that new number be used - corresponding to the 
>>particular extension
>>
>>
>>
>>SC XM-1      (for example for the first on in the Mobile extension)
>>
>>
>>
>>or
>>
>>
>>
>>SC XM-3.1.7   (for mobile — where 3.1.6  is the last SC number in 3.1 
>>series
>>
>>
>>
>>If it is an extension of a particular SC it could say
>>
>>
>>
>>  SC XM-3.1.7 (which extends  SC 3.1.3)
>>
>>
>>gregg
>>
>>
>>
>>>On Feb 22, 2016, at 8:36 AM, Sailesh Panchang 
>>><sailesh.panchang@deque.com> wrote:
>>>
>>>
>>>
>>>1. I understand that "The extension is not changing the SC in WCAG
>>>2.0, it is modifying the SC in the context of the extension", then
>>>should not the  statement, "Extension specifications are expected to
>>>offer modifications to existing WCAG 2.0 success criteria  ..." be
>>>worded differently to convey what is intended?
>>>2. Yes, "All of the details regarding numbering and association with
>>>the techniques are details that do need to be figured out", but this
>>>extension requirements doc should explicitly state that the SCs  in 
>>>an
>>>extension will not duplicate  an SC# from the WCAG 2.0.
>>>Else, an SC in the extension that has  a number identical to a WCAG
>>>2.0 SC will surely create confusion  as Greg pointed out in his first
>>>email especially with regard to documentation for techniques and
>>>understanding.
>>>It may not be very problematic for some changes  e.g. SC 1.4.3 in the
>>>extension say, only changes the ratio from 4.5:1 to 5:1 to make it
>>>stronger.
>>>But consider what will happen, if say, SC 3.3.2 in the extension
>>>begins with "Labels and instructions" instead of "Labels or
>>>instructions".
>>>
>>>I believe the above should be addressed, then the statement suggested
>>>by David will absolutely fit in and not create room for any 
>>>confusion.
>>>
>>>Thanks,
>>>Sailesh Panchang
>>>
>>
>>
>
>
>
>