Re: Coming to a decision on 2.2

Hi Alan,
> Ok, so with your example of stronger color contrast, how will it 
> âEURoesatisfy the original WCAG 2.0."
Because to satisfy a stronger extension means that the parameters of the 
luminosity ratio used in the original SC have been surpassed. Is that clear?
> [...] IâEUR^(TM)m sure the development community will say, âEURoewhy 
> should we meet a stronger color contrast for LV extension if our 
> current contrast meets the original already?âEUR? based on this 
> definition.
Because a new extension may be addressing a user need that wasn't 
envisioned in the original SC or guideline (just saying for the purposes 
of illustration).

Thanks

Josh

>
> "Extensions may provide additional accessibility requirements over and 
> above WCAG2, but in any case must satisfy the original WCAG 2.0."
>
> Hope that helps.
>
> Alan
>
> Sent from Mail for Windows 10
>
> From: josh@interaccess.ie
> Sent: Monday, February 22, 2016 3:48 PM
> To: ALAN SMITH; Mike Elledge; John Foliot; 'Katie Haritos-Shea'
> Cc: 'David MacDonald'; 'CAE-Vanderhe'; 'Jason J White'; 'Sailesh 
> Panchang'; 'Andrew Kirkpatrick'; 'GLWAI Guidelines WG org'
> Subject: 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 âEURoeover and aboveâEUR? 
> 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 âEUR~strongerâEUR^(TM)) 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 âEUR" 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 âEURoeLow 
> VisionâEUR? Success Criteria in name feels (to me) wrong.
> Â
> I had previously suggested an additional âEURoedot-numberâEUR? scheme 
> (such as your suggested 1.4.3.1) and that may be one way forward, 
> although again, looking at how weâEUR^(TM)ve addressed other 
> âEURoestrengtheningâEUR? 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 âEUR~headingsâEUR^(TM) of P, O, U, 
> or R) is more âEUR~flexibleâEUR^(TM) and/or consistent moving forward.
> Â
> If I were King of the World (which sadly IâEUR^(TM)m not) IâEUR^(TM)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 
> âEURoeLiving DocumentâEUR? type scheme, and that weâEUR^(TM)d 
> articulate specific Milestone dates, at which point all 
> âEURoeapprovedâEUR? new SC, along with the current WCAG 2.0 becomes 
> WCAG 2.1 [sic] âEUR" fully realizing that we canâEUR^(TM)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âEUR^(TM)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âEUR^(TM)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   âEURoeoffer modifications to the existing set of WCAG 
> 2.0 success criteriaâEUR? meaning that it would extend the set âEUR" 
> 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 âEUR" 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
> Â
>
>
>
>
> ------------------------------------------------------------------------