W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2017

Re: Concurrent Input Mechanisms

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Thu, 3 Aug 2017 20:33:30 +0100
To: w3c-wai-gl@w3.org
Message-ID: <0c6d1ca7-b8ca-6177-1218-280edeadb148@splintered.co.uk>
On 03/08/2017 19:45, White, Jason J wrote:
> I think Andrew’s suggested formulations are moving in the right 
> direction so far as clarifying the idea is concerned. Obviously, 
> restricting the available input modalities is not a good idea. On the 
> other hand, I don’t know how Web content can fail to satisfy this, in 
> practical terms, or how serious the accessibility issues are that result 
> if it does. In particular, surely most of the issues lie at the user 
> agent or operating system level.

Classic example: a page sniffs to see if Touch Events are present, and 
if so only hooks up touch event listeners (rather than traditional 
mouse, keyboard, generic `click` handlers, etc).

This falls apart on devices like laptops/desktops with both touchscreen 
AND traditional keyboard/mouse (e.g. Surface), and in situations where a 
nominally touch-only device like a phone or tablet has a paired keyboard 
and/or mouse.

The impact is that users are forced to just use the touchscreen. The 
fact that the keyboard in these situations doesn't work can be filed as 
a failure of 2.1.1, but forcing mouse users to use touchscreen falls 
between the cracks of current WCAG at the moment. This would hopefully 
fill that gap.

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 Thursday, 3 August 2017 19:33:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:16 UTC