RE: Coming to a decision on 2.2

John,

In my experience, living changing documents don't lend themselves well  to
laws and regulations that Accessibility has a dependency on.

Katie Haritos-Shea
703-371-5545
On Feb 22, 2016 11:19 AM, "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
>
>
>
>