Re[2]: Coming to a decision on 2.2

Doh! I see Jason bet me to that one..

Thanks Jason *smile.

Really this whole thing is about finding a way to ensure that current 
technology and user needs are being met. Its really WCAG ++, albeit in a 
modular way.

The interesting challenge is going to be dealing with the nexus between 
similar user group extensions (as JF was asking about) and that is open 
for discussion. In that case - we may need numbers for SCs with an 'x' 
prefix/suffix to denote it as an extension but without the specific TF 
acronym.

Thanks

Josh

------ Original Message ------
From: "ALAN SMITH" <alands289@gmail.com>
To: "Mike Elledge" <melledge@yahoo.com>; "John Foliot" 
<john.foliot@deque.com>; "'Katie Haritos-Shea'" <ryladog@gmail.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>
Sent: 22/02/2016 20:12:05
Subject: RE: Coming to a decision on 2.2

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