Re: Proposed amendment to 1.4.11 for WCAG 2.2

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> 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 <http://john.foliot.ca/demos/focuscolor.html>
> 
> JF
> On Oct 16, 2019, at 11:54 AM, Patrick H. Lauke <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 | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>