RE: Potential failure technique for WCAG 2.1 SC 2.5.6 - Concurrent Input Mechanisms

Hi Alastair and All,

My responses are prefaced with my name in bold inline below.

Brooks

From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: Monday, November 26, 2018 11:05 AM
To: w3c-wai-gl@w3.org
Subject: Re: Potential failure technique for WCAG 2.1 SC 2.5.6 - Concurrent Input Mechanisms

HI Brooks,

Interesting question, let me get a couple of things straight in my head:

> A sighted web page user tabs with a keyboard … then she arrows down in the dropdown list

Are you assuming that there is scripting for arrowing down the list, or do you mean she tabs down? Or is she also using a screenreader? This might not matter for the overall question, it just jumped out at me.

Brooks: My assumption was that in this particular scenario, there is scripting for arrowing down the list, such as what is used in one of the ARIA Authoring Practices 1.1 examples for the Menu Button widget<https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions.html>.

> must the web page content allow for both the keyboard focused option and the mouse hovered option to display visual focus indicators simultaneously?

Pedantically, the mouse-hover isn’t a “focus” indicator, which might have a bearing here.

Brooks: I understand.  I used the term “focus indicator” loosely for the purposes of this discussion. But, if the content owner decides to implement on hover styling that mimics on focus styling, then we have the issue I’m bringing to the group.

SC 2.5.6 doesn’t include any requirement for focus/hover indicators, it is phrased as “does not restrict use of input modalities”, so you could (theoretically) hide any mouse-hover indicators if the user has tabbed through the page, so long as the functionality still worked. I.e. you could click on the menu and it works.
Not advised, but possible.

Brooks: Let me turn this around from what you said.  I’m not worried as much about whether a mouse user will be able to successfully interact with the Menu Button widget options in the dual input scenario I’ve posed.  I’m more worried about whether a keyboard will be able to use the interface immediately after she has hovered over the menuitems in the dropdown with a mouse, and then chooses to complete the interaction with the widget using a keyboard.  If we remove keyboard focus indication whenever a mouse cursor hovers over any of the options, how will the user be able effectively use a keyboard without a persistent indication of keyboard input focus in place?

> Is being able to see where keyboard input focus was last positioned on the page a requirement for being able to use a keyboard at any time, even if the user has hovered over the page with a mouse since the last keyboard maneuver?

Not exactly, the requirement would be for the current focus to be apparent, but you could have hover-styles as well, at the same time. I think we have to assume that people know where their mouse is, so duplicate styles (if focus & hover have the same styles) are ok.

Brooks: So, I think I agree with where you are going with this.  Duplicate or comparable visual styles are OK for focus and hover, and it is OK to have two items highlighted at once in the dropdown – one for keyboard focus, one for what is currently hovered over by the mouse cursor.  But, is it fair to say that it is not OK to remove keyboard focus indication in the dropdown list of menuitems when user simply hovers menuitems, but does not click on any of them?

There are also circumstances where the focus can be changed by clicking with a mouse. E.g. you click on a correctly coded label and the focus would be placed in the input.

By default I don’t think that mouse-hover affects (keyboard) focus, you’d have to do some pretty strange scripting to achieve that. Is that the case you’re dealing with?

If it’s a drop-down/fly-out menu, I’d try and align mouse-click with keyboard-activate, but keep mouse-hover and keyboard-focus both active at the same time.
E.g. The menu opens with click/activate, you can tab through and activate, or click with a mouse at any time. Also, keyboard focus should be apparent, and allow hover to be triggered as well.

-Alastair

Received on Monday, 26 November 2018 19:35:42 UTC