- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Mon, 26 Nov 2018 17:12:52 -0500
- To: w3c-wai-gl@w3.org
It is likely the title of the SC might confuse some readers. The SC text does not use the word "concurrent". The Understanding doc too uses "alternative input mechanisms" or "variety of input mechanisms". That's why the question perhaps refers to using a keyboard to interact with a UI control and then switching to a mouse with the expectation of being able to see the effect of interacting with both keyboard and mouse concurrently. Sometimes on an iPhone I have seen the handwriting method of entering text (I often prefer to use this while entering user names / passwords / account#s - essentially short forms) does not work with some content. This might be an example of failure for this SC. It would also be a failure if it did permit one to use handwriting but did not permit one to switch back to using the alternative on-screen keyboard mid-stream. Thanks, -- Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc Phone 703-225-0380 ext 105 Mobile: 571-344-1765 On 11/26/18, Patrick H. Lauke <redux@splintered.co.uk> wrote: > On 26/11/2018 16:35, Newton, Brooks (Legal) wrote: >> Hi All, >> >> I’ve got a question I’d like to pose to the group about a potential >> failure technique for the AAA WCAG 2.1 Success Criterion for Concurrent >> Input Mechanisms. >> >> Here’s the setup for the question: >> >> A sighted web page user tabs with a keyboard into the content of the >> page and brings focus to a menu button widget. Using a keyboard, the >> user opens the list of options for the menu button widget by pressing >> the space bar, then she arrows down in the dropdown list to the 3^rd out >> of 5 options in the list. That 3^rd option displays a visual focus >> indicator, as it should. Next, the user grabs a mouse and hovers her >> cursor over the 1^st of 5 options in the menu button drop down. >> >> In order to satisfy SC 2.5.6, must the web page content allow for both >> the keyboard focused option and the mouse hovered option to display >> visual focus indicators simultaneously? >> >> 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? > > My gut answer would be: no, I'd say that once mouse movement is > detected, a site may even decide to hide the keyboard focus here so as > not to interfere somehow visually with the mouse hover. As long as once > the user goes back to the keyboard and moves the focus again the newly > focused item is highlighted/visibly focused, that would be fine to me. > And, as Alastair noted, the SC itself isn't concerned with visible focus > indication, only the more general concept that use of an input isn't > prevented somehow (i.e. that the site doesn't make simplistic > assumptions, a la "well the user started with the keyboard, so I don't > need to bother putting in mouse/touch listeners as they'll just use the > keyboard exclusively). > > P > -- > Patrick H. Lauke > > www.splintered.co.uk | https://github.com/patrickhlauke > http://flickr.com/photos/redux/ | http://redux.deviantart.com > twitter: @patrick_h_lauke | skype: patrick_h_lauke > >
Received on Monday, 26 November 2018 22:13:15 UTC