Re: Extension conflict/compatibility requirement

Sorry, I'm not sure how this got to general distribution.  Since it is on
the list let me explain.

I did not come lightly to the conclusion that 1.4.3 is an accommodation not
an accessibility criterion.

Understanding 1.4.3 has a mistake in its characterization of the need for
contrast minimums. The relationship between contrast minimum and visual
acuity is not as deterministic as Understanding 1.4.3 would imply.  I
originally doubted my understanding of the data so I contact Arditi
directly. He agreed with my interpretation.

 Here is what is known. (1) People with low visual acuity have higher value
for the minimum contrast before reading speed drops below 50% of optimum.
This bottom value is called the critical contrast. (Legge, Ruskin) (2)
Visual acuity and contrast are related, but not in the deterministic way
they are characterized in Understanding 1.4.3. (Arditi, Faye [2]) (3)
Contrast has almost no effect reading for people with central retina field
loss when the font size is sufficient (Legge, Rubin [1]).

Combining these three observations together we have the following: There is
a general need for higher contrast to support most people with low vision.
Setting minimum is not as helpful for a large minority of people with
central field loss, and for many it cause discomfort becaise central retina
field lows is often accompanied by light sensitivity (TSB).

It follows that setting a contrast minimum creates a benefit for some and a
disadvantage for others.  This is an example of an SC we do not want to
repeat, and it is the kind of SC that will cause conflict.  1.4.3 should be
replaced by something like:

1.4.3X A mechanism exists to enable users to increase or decrease the
contrast ration to a level that support sustained reading.

That would support accessible content much more than a fixed minimum. It
also conflict resistant.

I believe that a design flaw with WCAG 2.0 is its limited view of how much
flexibility is needed and possible for data.  Just as WCAG 1.0 set its
technological focus too narrow, WCAG 2.0 set its flexibility focus too
narrow.  Device diversity has pointed us in the right direction.

Wayne

[Arditi, Faye], Arditi, A. and Faye, E. (2004). Monocular and binocular
letter contrast sensitivity and letter acuity in a diverse ophthalmologic
practice. Supplement to Optometry and Vision Science, 81 (12S), 287.
[Legge, Rubin],PSYCHOPHYSICS OF READING: VI. TH
E ROLE OF CONTRAST IN LOWVISION,
http://gandalf.psych.umn.edu/users/legge/read6.pdf
[TSBVI], Specific Eye Conditions, http://www.tsbvi.edu/eye-conditions



On Tue, Oct 20, 2015 at 10:18 AM, Wayne Dick <wayneedick@gmail.com> wrote:

>
>
> On Tue, Oct 20, 2015 at 9:29 AM, Wayne Dick <wayneedick@gmail.com> wrote:
>
>> Hi Jon,
>> I misread your name and sent this to Josh.  I don't want this on the list
>> until our science is ironed out.
>> Wayne
>> ---------- Forwarded message ----------
>> From: Wayne Dick <wayneedick@gmail.com>
>> Date: Tue, Oct 20, 2015 at 8:58 AM
>> Subject: Re: Extension conflict/compatibility requirement
>> To: Joshue O Connor <josh@interaccess.ie>, Jim Allan <jimallan@tsbvi.edu>,
>> Andrew Kirkpatrick <akirkpat@adobe.com>
>>
>>
>> Dear Josh,
>>
>> I want to take this off the main list because it is delicate. I am
>> including Jim and Andrew because they head the LVTF. Even 4.5:1 is painful
>> for many. It hurts my eyes after reading a long time, and I know many in
>> the California Council of the Blind experience the same issue. It's not
>> that contrast sensitivity is not a factor, it is just that it is not the
>> only way to improve perception. Sometimes it is the wrong way. The science
>> that was used to determine this number was applied wrong. I confirmed this
>> correspondence Andres Arditi who was a key source.  There is not a
>> functional relation in the sense it is presented in Understanding 1.4.3.
>>
>> However, the real problem is in setting minims or maxims.  Low vision is
>> not a uni modal distribution. My group, central retina scotomas, is a large
>> sub population. We do respond well to increased brightness for any reason,
>> even to create legibility. Moreover, increased contrast imparts no benefit
>> regarding reading for this group. One of my friends uses 2:1 contrast ratio
>> and reads in a dark room.  Bob is probably out on the low end of the
>> distribution tail, but 2:1 is a lot less than 4.5:1 about which Bob said in
>> his frank way, "If I had to read that all day, I'd puke."
>>
>> When WCAG sets minimums and maximums it is moving into the realm of
>> accommodation. 1.4.3 should be replaced with an ability to adjust contrast
>> and polarity (dark on light vs light on dark).  This would enable
>> accommodation for  the majority who need higher contrast without excluding
>> those who require less brightness and hence less contrast. Note that people
>> with albinism and central retina scotoma constitute a very large minority
>> of people with low vision. My friend Bob may be a rare event, but the
>> general phenomenon is not. 1.4.3 is an example of a self contradictory SC.
>>
>> I hope you consider this carefully because it near the crux of the issue
>> with low vision.
>>
>> I can forward my communication with Andres Arditi if you like.
>>
>> Wayne
>>
>>
>>
>>
>>
>> On Fri, Oct 16, 2015 at 2:28 AM, Joshue O Connor <josh@interaccess.ie>
>> wrote:
>>
>>> Hi all,
>>>
>>> On the working group call this week there were a couple of interesting
>>> points raised regarding extensions that require further discussion. We also
>>> wish to engage other people on the list who were not on the call, and make
>>> sure that they are aware of some of the finer points and able to express an
>>> opinion here on the list.
>>>
>>> To sum up, two main 'themes' in our extension framework are extension
>>> compatibility, and the need to reduce, minimise or indeed remove any
>>> conflict between extensions.
>>>
>>> NOTE: As a thought experiment, one possible way to do that would be to
>>> have a 'MonoSpec' extension which combined the output from all TFs
>>> (Mobile/Cognitive/Low Vision) in a single spec. Potentially where care is
>>> taken to ensure that these extension SCs are fully compatible with each
>>> other there may be less 'conflict'.
>>>
>>> The 'PolySpec' extension approach would involve taking the SCs from each
>>> group and placing them in separate docs that conformance claims would be
>>> written against individually.
>>>
>>> While in principle, the contents of these docs would be more or less the
>>> same, the potential for conflict if there is only a 'MonoSpec' may be
>>> reduced. If only because a valid conformance claim would need to be written
>>> against it in toto. Also this approach would mean that devs would have to
>>> satisfy the success criteria in the MonoSpec fully, even if some are
>>> outside of the developers immediate area of interest. So in short could be
>>> a good way of conditioning developers to consider other user needs - rather
>>> than thinking "I need to make my content conform to just mobile, or low
>>> vision success criteria etc".
>>>
>>> Regarding extension conflict, in our current draft 'WCAG Extensions
>>> Framework' document it states: [2]
>>>
>>> "Ensure that all WCAG extensions are compatible with each other
>>> Extensions must not conflict with each other. This is important for the
>>> purpose of enabling content providers to implement support for more than
>>> one extension. For this reason will be critically important for group
>>> members working on different extensions to maintain good communication
>>> about extension work in progress."
>>>
>>> There are a couple of questions/points that arise:
>>>
>>> 1) Should we explicitly call out the need within the framework that
>>> there must NOT be conflict between extensions? It has been pointed out
>>> (rather practically) that it just may not be possible to avoid conflict
>>> with our extensions.
>>>
>>> 2) If we do explicitly call out this issue in our framework, it may help
>>> focus working group attention on carefully finding where there are
>>> conflicts in extensions (between there own group and others).
>>>
>>> 3) On a more granular level how do you think the framework should even
>>> define conflict?
>>>
>>> 4) Obviously while spec fragmentation is a concern inherent in the
>>> extensions discussion a final thought is the basic question; Is conflict
>>> always inherently bad? Can positive conflict or friction between various
>>> user requirements result in the end in better content, better user
>>> experience etc?
>>>
>>> What do you think?
>>>
>>> [1] http://www.w3.org/2015/10/13-wai-wcag-minutes.html
>>> [2] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework
>>>
>>>
>>
>>
>