RE: Visible controls (aka hidden controls)

Most of John’s changes were incorporated before the survey went out, diff here:
https://github.com/w3c/wcag/pull/1559/commits/53b3b14b349f9c5af5c92047224b89b8a1945e77


There is a potential understanding-doc update, but that shouldn’t affect the SC text or progress.

Cheers,

-Alastair


From: Michael Gower

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<mailto:gowerm@ca.ibm.com>
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:        John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>
To:        David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>
Cc:        Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto: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<mailto: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<https://html.spec.whatwg.org/multipage/media.html#attr-media-controls> - this prompted the addition of one of the exceptions on Tuesday's call.

Proposed edit: "Controls Page componentssuch 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<https://html.spec.whatwg.org/multipage/media.html#attr-video-poster>. 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 itselfis 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<mailto: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



CanAdaptSolutions Inc.

Mobile:  613.806.9005

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://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<http://www.davidmacd.com/disclaimer.html>

On Tue, Dec 8, 2020 at 7:22 PM Alastair Campbell <acampbell@nomensa.com<mailto: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<http://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<http://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<http://deque.com/>
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"