RE: Visible controls (aka hidden controls)

HI Alastair and others, I can only really describe a particular experience for low vision users – for other users the case is pretty strong as well but I can’t point to research.

A user uses 800x600 resolution at the default browser zoom.     The user looks closely at the monitor – say 4 inches from the display.  Due to the distance from the monitor, the acuity of the person and Scotomas (blind spots) the user is only able to clearly read  4 or 5 words on the screen in a small circle – but can see that there are objects, text, colors, and other items around on the page.   In fact there are hundreds of words or controls that appear – but are not legible. When a user can’t find what they are looking for the user starts moving their head around the screen looking for controls.   If that is not successful then using the mouse requires the user to jiggle the mouse and mouse his/her head around looking for the mouse pointer. Then hovering over objects one by one to find out what they do.  Using the keyboard means likely starting from the top of the page and tabbing through many times to find the content on the page – likely trying to visually track where the keyboard focus is on the page at each tab stop looking to see if something appears on focus.  Tracking the visual keyboard focus is very difficult as it jumps around, can be in different forms and go through many controls even when the page is WCAG conformant.  All of the while all of this moving around the screen with their head is causing terrible neck pain.  Keep in mind that users with low vision are likely moving their physical head side to side up and down continually as they mouse over each and every control.  It’s not just moving your eyes and if it were trying to control your eye gaze when you have nystagmus is exhausting as well.

Thus,  one of the main challenges is simply locating related controls on the screen, moving the mouse from control to control or getting the keyboard to the point where you were looking and tabbing.  It’s not uncommon for a low vision user to be looking where the mouse or keyboard is not located – for some users most of the time the mouse or keyboard is not where they are reading!   One user I am describing is not using any magnification software but the text is large enough on the screen to read – but they can only read a few words clearly – they scroll through the screen with the mouse wheel.

Finding content by searching visually is very exhausting.  When a user doesn’t see something on the screen they assume it must be around but they are just missing it, it’s in their blind spot or it must be hidden in a menu, etc.  Then they have to go searching until they likely give up.

On a separate note most screen readers today do not focus elements when the virtual/browser cursor reaches content.  NVDA and VoiceOver on iOS use to but I don’t believe they do anymore – JAWS has never to my knowledge.  Many screen reader users are not tabbing around the page  This means for screen reader users unless there are clear roles or hidden instructions screen reader users may not be aware that they need to tab to focus an element.   Most advanced users are navigating by heading, paragraph, control, etc. which only moves the screen reader’s point of regard and not the system focus.

For speech recognition users hovering the mouse would require using a mouse grid and use of the keyboard to focus content would require saying press tab to move from control to control.  This is simply not how users of speech recognition use their technology.  Most users are activating controls by speaking the name of the control or by roles such as click link, etc.  Trying to focus or hover just to find out if the control had something on focus/hover would be verbally exhausting.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Thursday, December 10, 2020 6:49 PM
To: John Foliot <john.foliot@deque.com>; 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)

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.

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<mailto:john.foliot@deque.com>>
Sent: 10 December 2020 21:40
To: Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.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)

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