Re: Re[2]: Coming to a decision on 2.2

The "x" number might work to easily distinguish what is an extension and
what is the original.


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 Mon, Feb 22, 2016 at 3:54 PM, josh@interaccess.ie <josh@interaccess.ie>
wrote:

> 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Mike Elledge <melledge@yahoo.com>
> *Sent: *Monday, February 22, 2016 2:56 PM
> *To: *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>
> *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
>
>
>
>
>
>
>
>