Re: Concurrent Input Mechanisms

I agree that this is what we are trying to address, but the question has been raised asking for specific examples. Is there a specific case of your classic example that you can point to?


Andrew Kirkpatrick
Group Product Manager, Accessibility

On 8/3/17, 15:33, "Patrick H. Lauke" <> wrote:

>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.
>Patrick H. Lauke
> |

> |

>twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 4 August 2017 15:32:40 UTC