Re: Extension conflict/compatibility requirement

Hi Dick

The language in the SC was worked out directly in consultation with Aries, and he reviewed the final wording -  so it is interesting that you cited him as a refutation of it.  
Note that 1.4.3 also takes into account color deficiencies - so low vision alone factors alone will not get you what you are looking for. 

I agree with you that low vision is not deterministic .  In fact nothing in the guidelines is deterministic.   
Also as you know, there is no such thing as ‘low vision’ in the first place as any single thing.  Low vision and even low visual acuity is variant.    And as you point out - this SC would benefit some types of low vision but not others.  No provision will benefit all types.     


The rest of your discussion is about things that were all known at the time the SC was created.   However there are many ways to lower contrast if it is too high — but it is much harder to increase it if it is low.  Hence the reason a minimum contrast is good and why it was specified. 

I think someone else posted that the purpose of WCAG was not to make things accessible — but to make it possible to make things accessible.    For example, WCAG does not require that pages self voice - but that they are able to be voiced (that screen readers and other AT can access the information in machine readable form).       

Ditto for contrast.  There is no contrast that is right for everyone.   Setting the contrast where it is — was a complex multi factored process that too into account low vision, color deficiency,  color spaces etc.   Looking at only one of these dimensions - denies the others - and won’t get you the optimum minimum contrast value.  And you want to choose one that is easiest to modify to match widest range of users. 

Of course, NO contrast value will be the optimum for everyone. 

The goal was to make it within reach directly (or though adaptation) for the largest number of people that it is practical for. 

THE BEST SOLUTION, might be to require that all pages have infinite contrast variability - in all color combinations - using an interface that is familiar and understandable by all potential viewers.    But that is not practical or possible to my knowledge.  Just the interface that is “familiar and understandable by all potential viewers” is outside of our reach - if you really include all potential viewers. 

best 

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Oct 20, 2015, at 1:19 PM, Wayne Dick <wayneedick@gmail.com> wrote:
> 
> 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 <http://gandalf.psych.umn.edu/users/legge/read6.pdf> 
> [TSBVI], Specific Eye Conditions, http://www.tsbvi.edu/eye-conditions <http://www.tsbvi.edu/eye-conditions>
> 
> 
> 
> On Tue, Oct 20, 2015 at 10:18 AM, Wayne Dick <wayneedick@gmail.com <mailto:wayneedick@gmail.com>> wrote:
> 
> 
> On Tue, Oct 20, 2015 at 9:29 AM, Wayne Dick <wayneedick@gmail.com <mailto: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 <mailto: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 <mailto:josh@interaccess.ie>>, Jim Allan <jimallan@tsbvi.edu <mailto:jimallan@tsbvi.edu>>, Andrew Kirkpatrick <akirkpat@adobe.com <mailto: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 <mailto: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 <http://www.w3.org/2015/10/13-wai-wcag-minutes.html>
> [2] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework <https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework>
> 
> 
> 
> 
>