RE: Visible controls (aka hidden controls)

John, I think you should consider generating a PR of the Understanding doc 
with those changes. I suspect most are friendly, and likely easier for 
some folks to parse as PR?

Michael Gower
Senior Consultant in Accessibility
IBM Design


1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:   John Foliot <john.foliot@deque.com>
To:     David MacDonald <david@can-adapt.com>
Cc:     Alastair Campbell <acampbell@nomensa.com>, "WCAG list 
(w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
Date:   2020/12/09 03:27 PM
Subject:        [EXTERNAL] Re: Visible controls (aka hidden controls)



Erm... s/visibly persistent controls also/easily discoverable...           
  



This Message Is From an External Sender
This message came from outside your organization.



Erm...

s/visibly persistent controls also/easily discoverable controls

Sorry 'bout that.

JF

On Wed, Dec 9, 2020 at 6:17 PM John Foliot <john.foliot@deque.com> wrote:
Johnny come lately...

Hi Alastair, group,

As I review this, I am struck by how many times we hammer folks over the 
head with 'cognitive' in the Intent statement. While I appreciate that for 
this user-group, this requirement is indeed critical*, visibly persistent 
controls also can benefit Low Vision users, supports interfaces and 
form-factors where "mousing over" cannot be reasonably achieved, etc.

Might I propose the following editorial edits:

Intent of Visible Controls
The intent of this Success Criterion is to ensure that controls needed to 
progress or complete a process can be easily found by people with 
cognitive disabilities users when they are needed.
People with low executive function, impaired memory, and other cognitive 
and learning disabilities may not be able to find controls needed to 
progress if they are hidden until focus is placed on them or a pointer 
hovers over them. They may also not remember where the control is the next 
time they interact with the site. Additionally, some methods for exposing 
hidden controls (i.e. mouse-over) may not be supported by all platforms or 
user-agents.
Some design approaches hide controls needed to complete tasks and require 
certain user interactions, such as mouse-over, to display these controls. 
These required interactions can leave some users without a perceivable 
path forward.

As well, as I mentioned on Tuesday's call, the language around media 
player controls is (at best) confusing:

Mutlimedia Controls (Note, the current draft has a spelling mistake: 
Multimedia)
Controls such as video players, web chats, and carousels include controls 
that are only visible on hover since they overlay the contents being 
displayed. The video content itself is considered to be the "Information 
needed to identify user interface components", like the top visible part 
of a drop-down that shows sub-items. Some users may still struggle if 
media controls are not persistently visible, so there is benefit to 
providing a mechanism for people to keep the controls visible.
  "Controls such as video players,..." 
[JF: Video players are not controls, they are components. Specifically, 
since HTML5, the web browser is the media 'player', where content authors 
can either furnish their own scripted and styled controls, or they can 
fall back to native controls furnished by the browser by using the 
@controls attribute - this prompted the addition of one of the exceptions 
on Tuesday's call.

Proposed edit: "Controls Page components such as video players, web chats, 
and carousels frequently include controls that are only visible on hover 
since they overlay the contents being displayed." - while also noting that 
"web chats" are not Multimedia content, although I agree that mentioning 
this type of component, which often acts similar to other forms of active 
media containers, is useful to the understanding. Perhaps instead of 
"Multimedia controls" we fall back slightly to a more generic "Embedded 
controls"] 

  "The video content itself is considered to be the "Information needed to 
identify user interface components"..."
[JF: the presence of the <video> element in a containing document may not, 
at the start, be rendering a "video" - it may in fact be displaying a 
static image supplied via the @poster attribute. Additionally, while it is 
common to see a "triangle" (start) button superimposed over the video 
bounding region, that is but a current convention, and not a mandated 
rendering requirement in the HTML specification.

Proposed edit:  "The video content The presence of these types of embedded 
controls in a containing document itself is considered to be the 
"Information needed to identify user interface components"..." 
No hills worth dying on here, but offered as broader feedback to the 
group.

JF

(*Critical - Important? Useful? Necessary? Thesaurus time...)



On Wed, Dec 9, 2020 at 4:53 PM David MacDonald <david@can-adapt.com> 
wrote:
Regarding the last proposed rewording 
>All functionality of the content can be operated by user interface 
components without requiring pointer hover or keyboard focus to first make 
the user interface components visible.”

I think we better capture it with the current updated wording and the 
current update seems easier to understand than this one.

Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Mobile:  613.806.9005
LinkedIn 
twitter.com/davidmacd
GitHub
www.Can-Adapt.com 
   
  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy


On Tue, Dec 8, 2020 at 7:22 PM Alastair Campbell <acampbell@nomensa.com> 
wrote:
Hi Folks,
 
I updated the draft based on our discussion today, you can see the 
changes:
https://github.com/w3c/wcag/pull/1557/files

 
And a previewed:
https://raw.githack.com/w3c/wcag/master/understanding/22/visible-controls.html

 
I did a quick pass on updating the understanding document, but we still 
need to add some more information about the exceptions. (E.g. the example 
for skip links.)
 
AndrewK had a last minute suggestion of:
“All functionality of the content can be operated by user interface 
components without requiring pointer hover or keyboard focus to first make 
the user interface components visible.”
 
But we didn’t have time to consider that sufficiently during the meeting.
 
If anyone has any thoughts or objections to this approach, please do 
comment here.
 
Kind regards,
 
-Alastair
 
-- 
 
www.nomensa.com
tel: +44 (0)117 929 7333 / 07970 879 653
follow us: @we_are_nomensa or me: @alastc
Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT
 
Company number: 4214477 | UK VAT registration: GB 771727411
 


-- 
John Foliot | Principal Accessibility Specialist
Deque Systems - Accessibility for Good
deque.com 
"I made this so long because I did not have time to make it shorter." - 
Pascal "links go places, buttons do things" 





-- 
​John Foliot | Principal Accessibility Specialist
Deque Systems - Accessibility for Good
deque.com 
"I made this so long because I did not have time to make it shorter." - 
Pascal "links go places, buttons do things"