RE: Extension conflict/compatibility requirement

Excellent thoughts.
Will be thinking this through for a while.


Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov<mailto:accessibility@dhs.gov>

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.

From: Wayne Dick [mailto:wayneedick@gmail.com]
Sent: Tuesday, October 20, 2015 3:10 PM
To: Jonathan Avila
Cc: GLWAI Guidelines WG org
Subject: Re: Extension conflict/compatibility requirement

Hi All,
Allen and Jon I actually do agree.  Right now writing assistive technology to support robust change in visual style is profoundly difficult.  The structure of modern content and user agents restrict this much more than is needed.
Let's just focus on contrast, but font-size and other visual presentation metrics follow a similar logic.  A page should make sense without the the author's style.  There are exceptions like conditionally hidden content, but in general the user should be able to see the content of web content without having to view the author's presentation for an audience with normal vision.  In (HTML, CSS, JavaScript) this is possible and it can be made extremely efficient without any modification to the user agent.  For other technologies it would involve both content and UA.  In this context the only limit on contrast is the user preference, because once the author's preference is removed, the user can replace it as needed.  Until the 508 Refresh passes this is in fact the law for (HTML, CSS, JavaScript).
In general this could be accomplished in many ways.  A more robust API would enable reconstructed content that is restyled.  There are many ways to address user style needs without placing unreasonable limits on developers or user agents.
Consider the problem of polarity (dark on light vs. light on dark). Almost every OS can address this.  How much harder would a personalized contrast ratio be to support.  Anyone who practices progressive enhancement with W3C technology can do it automatically. I really think the concern about enabling wide variety in user choice is something of a bugaboo.  As soon as it was deemed necessary for a general audience, mobile developers creates schemes to support 600% enlargement almost overnight.
I am sure we will encounter real limits, but I don't think we are even close.
Wayne

On Tue, Oct 20, 2015 at 11:36 AM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:

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

We’d need to define how sustained reading is measured and for what population under what conditions..  We’d also need to define what sufficient mechanisms are acceptable – requiring the user to load a custom stylesheet?  Using a plug-in? Accessibility platform filter?  What about inverse colors?

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
Phone 703.637.8957<tel:703.637.8957>
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Wayne Dick [mailto:wayneedick@gmail.com<mailto:wayneedick@gmail.com>]
Sent: Tuesday, October 20, 2015 2:20 PM
To: Jonathan Avila; GLWAI Guidelines WG org
Subject: 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<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

[2] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework