Re: Quick (hopefully) question about WCAG 2 glossary definition of "keyboard interface"

On 28/06/2016 20:51, Gregg Vanderheiden RTF wrote:

> Actually voiceover would fail the SC (swiping is not a keystroke) except
> that voiceover ALSO allows all actions (including all the navigation
> gestures) to be done through its bluetooth keyboard interface.    SO it
> meets the SC  *not* because of swipes — they are gestures  — but because
> everything CAN be done through keystrokes via the keyboard interface.

Swiping moves the focus for sequential navigation. It is the baseline 
way in which VoiceOver/iOS, TalkBack/Android etc users interact. Not 
everybody uses an external bluetooth keyboard - that's an optional 
accessory (compared to desktop/laptop devices, where it's a given that 
it's present as the lowest common denominator).

> If 2.1 wants to require that gestures also be possible (I can’t see that
> as a good idea though) then it would be ok.
> But that SC was specifically designed to be sure that everything could
> be done by people who cannot make the gestures.  SO gestures should not
> be somehow equated with that SC in WCAG 2.0

What I'm proposing, fundamentally, is that the distinction that needs to 
be made, really, is not between a gesture/mouse/keyboard, but rather: 
content is operable whether you're using a pointer input (a touch, 
stylus, mouse, headwand...anything that lets you pinpoint a particular 
x/y coordinate somewhere on the screen) or an alternative means of 
moving the focus / navigating (be it a keyboard or keyboard-like 
interface, a switch input, VoiceOver/iOS swipe gesture, etc) and that 
you want to make sure users don't get trapped when using this method 
compared to users who can use the pointer input.

> I don’t think that would be a good idea.  the definitions are normative
> so you can’t change them except with a new version — and if new versions
> are not supposed to weaken 2.0 - making gestures be equivalent to some
> keystrokes would weaken 2.0 provisions by eliminating the protection for
> people who cannot make those gestures.

It wouldn't weaken the provision in my view - it opens it up to more 
types of inputs while retaining what I think is the underlying idea: 
that an interface should not require a user to be able to use a pointer, 
but that it must also work with non-pointer inputs.

> I DO think it is GREAT that gestures also be possible.   Just like it is
> great that there are mouse ways to do things done by keyboard.   Both
> should be available to users.  But keyboard access should always be one
> option.

And keyboard access would still be one of the options, as it's the most 
common non-pointer/sequential navigation interface in circulation. Just 
that on devices which are primarily touchscreen driven the most common 
non-pointer/navigation paradigm is functionally the same, but does not 
send "keystrokes" - the effect is the same though, in that it moves the 
focus.


-- 
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 Tuesday, 28 June 2016 20:24:35 UTC