RE: Visible controls (aka hidden controls)

Jon wrote:
> I’d vote to add in users with low vision as this criteria has specific benefits to this group.  I’d further summise that it has benefits to other groups as well

Ok, but we need a bit more than surmising, do we have any references for that? It is a question we have to answer for new criteria: what is the research backing? It doesn’t have to be specific to the exact topic, but something that speaks to what issues are caused by invisible-until-hover controls for a particular group.

I can’t see anything in the low-vision user needs<https://www.w3.org/TR/low-vision-needs/>, and given the adaptations of reduced viewport size (zoom/mag) and a mouse-heavy interaction, I think it would need some explaining.

I’m not against adding other user groups, but it would need explanation, example and some form of reference. If someone wants to write that up, great, but I’d rather prioritise refinements based on active issues.

E.g. tackling these:
https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%223.2.7+Hidden+Controls%22+-label%3A%22Survey+-+Added%22+-label%3A%22Duplicate%22+-label%3A%22Survey+-+Ready+for%22


Cheers,

-Alastair


From: John Foliot <john.foliot@deque.com>
Sent: 10 December 2020 21:40
To: Jonathan Avila <jon.avila@levelaccess.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Visible controls (aka hidden controls)

+1 Jon.

This is why I had originally proposed to broaden the overall scope in the opening sentence, but leave the second, COGA specific sentence in place to firmly put focus on the *primary* beneficiary group.  This proposed SC has specific benefits for COGA users, but for other user-groups as well, and I fear we lose something when we get too narrow - it's not adding clarity, it's overly-filtered (IMHO).

JF

On Thu, Dec 10, 2020 at 3:31 PM Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:
I’d vote to add in users with low vision as this criteria has specific benefits to this group.  I’d further summise that it has benefits to other groups as well such as users with motor disabilities including those who use speech recognition software as tabbing around and hovering are likely things that would be more challenging for this group.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Sent: Thursday, December 10, 2020 1:09 PM
To: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>
Cc: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Visible controls (aka hidden controls)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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




--
​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"