Re: Finding examples which demonstrate "Concurrent Input Mechanisms"

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.

Patrick H. Lauke | |
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 14 February 2018 22:24:22 UTC