Re: Proposed amendment to 1.4.11 for WCAG 2.2

I would say we should take caution in determining what states need to be visually identifiable, so as to not overload the cognitive resources of users. I write a lot of research based articles on cognition, mental fatigue, and design. Below are excerpts from a neurological study of mental fatigue caused by processing visual information.

“Mental fatigue is a form of fatigue, induced by continuous task performance. Mentally fatigued people often report having a hard time keeping their attention focussed and being easily distracted. In this study, we examined the relation between mental fatigue, as induced by time on task, and attention-related changes in event-related potentials (ERPs). EEG, reaction times and response accuracies were obtained from 17 healthy volunteers during two hours of task performance on an adapted Eriksen flanker task. In this task, the size of targets and flankers was manipulated to discern neuronal processes that are related to processing of relevant information from processes related to the processing of irrelevant information. The ERP data showed that effects induced by target size manipulation were not affected by time on task, while an initial effect of flanker size manipulation decreased gradually with increasing time on task. We conclude that attention was affected by mental fatigue, in the form of a decrease in the ability to suppress irrelevant information. In behavioural results, this was reflected by a tendency of participants to increasingly base their response decision on irrelevant information, resulting in decreased response accuracies.” https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3485293/




[Headshot of David Fazio in a blue button down shirt, with red and silver diamond pattern tie, and contrasting blue Alpaca sport coat]

David Fazio, President| [signature_394334115] <https://www.linkedin.com/in/davidpfazio/>
[Helix Opportunity. Harmony at work logo]| [signature_946089949] <https://www.linkedin.com/company/6668894/admin/>
P. 510.590.7363| e. dfazio@helixopp.com<mailto:dfazio@helixopp.com>| W. www.helixopp.com<http://www.helixopp.com>

Book:
         [Harmony at Work: The Business Innovator's Guide to Profiting from the Growing Disability Demographic by Creating Meaningful Consumer Experiences for Everyone (The Harmony at Work Series Book 1) by [Fazio, David]] <https://www.amazon.com/Harmony-Work-Innovators-Demographic-Experiences-ebook/dp/B00RZRK7MC/ref=sr_1_1?ie=UTF8&qid=1422597881&sr=8->


Articles: Global Initiative for Inclusive Information Communication Technology<http://g3ict.org/resource_center/newsletter/articles_written_by_author/p/authorId_104468>|  Helix Opportunity Blog<http://www.helixopp.com/blog.html>


Videos: 10 Minutes About Helix Opportunity<https://youtu.be/elR_nLiiSAY>| Understanding the Disability Market Value<https://youtu.be/jr1DubRwML8>| Billion Dollar Consumer Market of Americans with Disabilities<http://youtu.be/X6SA4hX4FtQ>|

Designing Smart Cities Like Designer Drugs<https://youtu.be/43tRoowboDw>| CBS Interview of David Fazio<https://www.youtube.com/watch?v=Log3EkEYe24>| Accessible Americas V High-Level discussion: Sustainable Development Goals & Digital Inclusion. Creating equal opportunities in the Information Society.<https://youtu.be/PEwloyhMI04>




From: Andrew Somers <me@AndySomers.com>
Date: Friday, October 18, 2019 at 2:57 PM
To: John Foliot <john.foliot@deque.com>, Wilco Fiers <wilco.fiers@deque.com>
Cc: WCAG <w3c-wai-gl@w3.org>, AGWG Chairs <group-ag-chairs@w3.org>, Alastair Campbell <acampbell@nomensa.com>, David MacDonald <david100@sympatico.ca>, Andrew Kirkpatrick <akirkpat@adobe.com>
Subject: Re: Proposed amendment to 1.4.11 for WCAG 2.2
Resent-From: <w3c-wai-gl@w3.org>
Resent-Date: Friday, October 18, 2019 at 2:57 PM

Eh, because apparently I must like sticking my fingers into an electrical socket to see if the power’s on, I feel the urge to ask regarding:

 Visual information required to identify user interface components in all their states

All States?

  *   What about their hidden states? How do you visually identify a component in a hidden state?  Does a locked state need differentiating from other non-accessible states? Irrelevant states?

  *   What about transient states? Especially where the transient part of the state adds little to no useful meaning? Such as/including state changes that are essentially decorative/ornamental as opposed to meaningful?

  *   Does “visual info required…all their states” imply that all states must be distinguishable from each other? And all other states?

EXAMPLES:
Mozilla lists 60 pseudo classes and 35 pseudo elements (some with marginal browser support). And there are clearly many states that do not really “need” to be invoked, styled, or identified.

Such as :active

Sometimes used — I like to use it to have a “down” motion when clicking a button for instance. When I use it there is no change of luminance contrast, nor color, size, nor border. Only a small Y offset to create the “feel” of a pressing action. But styling this transient state is not necessarily that common, and usually unimportant. The actual “contrast” I am using is “positional contrast” which is not defined in WCAG 2.x that I know of (might be in future Silver “Visual Contrast” TBD)

For another example there are many cases where  :visited  is not a state needing display. You don’t need  :visited  for links to common locations like the Home page, the Search page, the User’s Profile.  :visited  is certainly useful for external links and content links.

  :active   is also not needed much of the time, but possibly needed for a clickON/clickOFF meta control.

DISCUSSION:
The current language  “...and states” does not imply a requirement to use any particular state (good). Changing to “in ALL their states” would seem to imply addressing more, or (yikes!) all available? Possible??? Instead of clarifying, I find this adds some ambiguity due to the number of states that are essentially optional.

Also, in discussions with Cybele relating to cognitive aspects of usability, excess contrast, including lots of feedback, motion, color, etc. can have a detrimental effect for many cognitive needs. For instance too many states and state changes leading to information overload and stress, confusion, and disorientation.

There are research-recognized need-cases for simpler, more streamlined UIs, with minimized stimulus, minimized contrasts, & minimized distractions.

~~TL/DR~:

MY OPINION:
As such, I am concerned about any language that implies a requirement to extend or add state information or feedback that is not actually required for usability.

PLEASE CONSIDER AN ALTERNATE:

Visual information required to identify user interface components and those states required for understanding the functionality of the component.


Thank you,

Andy
Undersecretary to the National
Department of Writing Really
Long and Excessively Detailed
Emails which are Nevertheless
Useful for Those Needing to
Appear Busy at the Moment
and Insomniacs.


On Oct 17, 2019, at 8:03 AM, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:

+1 to an editorial change in 2.2

 > When Alastair was explaining his perspective on it... He said that the focus indicator could basically be ignored for 1.4.11 because it becomes part of the control as soon as the control has focus.

FWIW, I have never agreed with Alastair's interpretation there, because focus indication (and contrast) is (should be?) primarily between the control and the background, and not between the control itself in various states (although that too can be a consideration). Alastair's interpretation allows for a white 'control' (for example a radio button) on a "blue" background, where in Chrome and Safari the native focus indication is also blue - thus you cannot see the focus indication. I documented this a while back: http://john.foliot.ca/demos/focuscolor.html


JF
On Oct 16, 2019, at 11:54 AM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:

On 16/10/2019 17:04, David MacDonald wrote:
[...]

CURRENT
"Visual information required to identify user interface components ***and*** states...
SUGGESTED
Visual information required to identify user interface components ***in all their*** states

I'll admit that I've always understood the current one to mean the same as the suggested one, but I can see how it could be misread. As it doesn't change the (intended) meaning of the SC, this should be a straightforward enough non-substantive change of normative wording.

+1

--
Patrick H. Lauke

www.splintered.co.uk<http://www.splintered.co.uk> | https://github.com/patrickhlauke

http://flickr.com/photos/redux/ | http://redux.deviantart.com

twitter: @patrick_h_lauke | skype: patrick_h_lauke