- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 14 Feb 2018 22:23:58 +0000
- To: Chuck Adams <charles.adams@oracle.com>, w3c-wai-gl@w3.org
On 14/02/2018 21:50, Chuck Adams wrote: >> I'd be careful about the overlap here with WCAG 2.0 2.1.1 Keyboard. The >> aim for concurrent input mechanisms is not to test whether or not the >> site works with a keyboard, but rather to check that it is possible for >> a user to, essentially, switch between the inputs they have available. >> i.e. if a user started off interacting with the mouse, and the site then >> STOPPED allowing any sort of keyboard interaction, that would be a >> failure of this SC. or is a site detects that a touchscreen is present, >> and STOPS working for mouse or keyboard users. > > Here's where I've had some mixed feelings. While I agree with you that overlapping standards is beyond the scope of my assignment, my thoughts were that if I am going to find an example site that we would represent as meeting "Concurrent Input Mechanisms", it really should behave cleanly. The ideal site would conform to all the standards. I'd like to find a site where there aren't "blatent" accessibility issues. Sure. What I meant, more clearly, was: if a site fails 2.1.1 because some functionality isn't working with the keyboard , that's not necessarily a failure of 2.5.4 Concurrent Input Mechanisms. But of course your approach is right to first find a site that does actually work (partially or ideally fully) with keyboard, and THEN determine if in the presence/with the use of other input mechanisms that keyboard interaction is then somehow blocked/removed/ignored. 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 Wednesday, 14 February 2018 22:24:22 UTC