RE: Visible controls (aka hidden controls)

Thanks John,

I’ve incorporated most of those, slightly simplified in places:
https://github.com/w3c/wcag/pull/1559/commits/53b3b14b349f9c5af5c92047224b89b8a1945e77


The two I didn’t update were:

  *   “can be easily found by people with cognitive disabilities users when they are needed”.
This SC comes from a COGA point of view, and we should be clear about that. If there are additional benefits, great, but let’s keep it clear.

  *   Also: “interactions can leave some users without a perceivable path forward”.
This part of the intent is trying to make a point about the experience, and from the users’ point of view it is “without a path forward”, which (IMHO) makes the point more strongly.

This will be back up for review next week.

Kind regards,

-Alastair


From: John Foliot

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 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<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 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...)