RE: Coming to a decision on 2.2

Hi Gregg

You are quite right, I was very careless in my wording – it was late!

I accept that it is not high contrast. However the “at least” wording in the success criterion does suggest that higher contrast is the aim. Whereas this may benefit most users, it may be encouraging contrast levels that will cause a problem for a subset of users (especially many people with dyslexia).

The conclusion is that, from a COGA TF perspective, we need to be sure that users will have the opportunity to reduce contrast. If it is fulfilling its aims, the COGA TF needs to emphasise this point in some way. So the challenge is to see how this can best be done in the context of a stable WCAG 2.0.

Best regards

Mike

From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org]
Sent: 23 February 2016 01:54
To: Michael Pluke <Mike.Pluke@castle-consult.com>
Cc: Neil Milliken <Neil.Milliken@bbc.co.uk>; John Foliot <john.foliot@deque.com>; Katie Haritos-Shea <ryladog@gmail.com>; David MacDonald <david100@sympatico.ca>; 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

Hi Mike

1.4.3 does NOT REQUIRE high contrast.    It requires a minimum contrast.

It required 4.5:1      High contrast is 20:1

Because of other provisions in WCAG low contrast can also be done — and is recommended.

The whole WCAG is designed to allow customization of presentation to people with different disabilities.  It does not in any way prescribe any presentation or limit presentation of information in any way.


Where is all the misinformation coming from?

gregg

On Feb 22, 2016, at 6:19 PM, Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>> wrote:

I’d like to strongly support Neil’s concern. He raises an issue that has also been identified by the ISO TC 173/WG 10 “Assistive products for cognitive disabilities” group. They have identified a major “problem” with WCAG 2.0 that the existing 1.4.3 requires a high contrast setting that acts against the needs of many users with dyslexia.

In the real world the answer to “solving the problem” caused by high contrast is quite simple, users need to be able to invoke a suitably calibrated “Reduce White Point” mode (as is currently available in iOS).

The dilemma for W3C is that any Low Vision extension that calls for greater contrast will be seen as worsening the situation for users who are adversely affected by high contrast. A Cognitive extension would be helping some of its users if it required lower contrast.

In practice, the COGA TF recognises that any changes to the “core” WCAG success criteria should only be expressed in terms of having an option to have reduced contrast.. The coherence of the WCAG extension model can only be preserved if other extensions express any proposal to (increase) contrast as an option and do not impose this solution on all users.

Individualization will be the key to allowing different users to be able to invoke the options that meet their needs and supress those that work against their needs. The COGA TF extension proposals already rely heavily on the need for individualization.

Best regards

Mike


From: Neil Milliken [mailto:Neil.Milliken@bbc.co.uk]
Sent: 22 February 2016 19:28
To: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>; 'Katie Haritos-Shea' <ryladog@gmail.com<mailto:ryladog@gmail.com>>
Cc: 'David MacDonald' <david100@sympatico.ca<mailto:david100@sympatico.ca>>; 'CAE-Vanderhe' <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>; 'Jason J White' <jjwhite@ets.org<mailto:jjwhite@ets.org>>; 'Sailesh Panchang' <sailesh.panchang@deque.com<mailto:sailesh.panchang@deque.com>>; 'Andrew Kirkpatrick' <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Coming to a decision on 2.2

I beg to differ on increasing contrast.  High contrast is a nightmare for some people like me with dyslexia.  We require sufficient contrast - too high and we start climbing the walls...
________________________________
From: John Foliot [john.foliot@deque.com<mailto:john.foliot@deque.com>]
Sent: 22 February 2016 19:19
To: '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
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<mailto:john.foliot@deque.com>>
Cc: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; CAE-Vanderhe <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>; Jason J White <jjwhite@ets.org<mailto:jjwhite@ets.org>>; Sailesh Panchang <sailesh.panchang@deque.com<mailto:sailesh.panchang@deque.com>>; Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org<mailto: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<mailto: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<mailto:gregg@raisingthefloor.org>]
Sent: Monday, February 22, 2016 12:00 PM
To: Sailesh Panchang <sailesh.panchang@deque.com<mailto:sailesh.panchang@deque.com>>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; Katie Haritos-Shea <ryladog@gmail.com<mailto:ryladog@gmail.com>>; John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Jason J White <jjwhite@ets.org<mailto:jjwhite@ets.org>>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org<mailto: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<mailto: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




----------------------------

http://www.bbc.co.uk<http://www.bbc.co.uk/>
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------