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

gregg

> On Jun 28, 2016, at 4:24 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> 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).

All this is correct.   except the least common denominator part.   People who cannot use swipes can use the keyboard.    

Saying that we can ignore the keyboard — and choose something less accessible as all that is required because it is included — would be like saying screen reader compatibility should be replaced by something less that is included rather than screen reader compatibility because screen readers are not included in all PCs and not everyone has a screen reader on their PC.

We are in a mobile world here — but the parallel is the same. 

With keyboard access I can use an alternate keyboard, a sip and puff alternate keyboard, a speech control alternate keyboard,  a miniature keyboard, a large keyboard and many other input devices to control my iPhone (or any mobile device).   All of these and much more are cut off if you say  “swipes can replace keyboard access” 

Again - because iPhone provides a keyboard equiv for each navigation gesture — the iPhone is completely keyboard operable and meets WCAG 2.0 keyboard SC.    If it did not - and swipes were the only way then it would fail.


Here we are talking about web content though — and it needs to be accessible on both Pcs and mobile.    So you need keyboard access for all the places and mobile devices taht don’t have swipe nav. 


IF YOU ARE TALKING ABOUT ADDING A NEW requirement  (that all content be navigable BY BOTH the keyboard AND gestures )— then you have  different problem.  The gesture control is not from the web content but from the iPhone and the author has no control of that…. 

Help me here.   We are going back and forth here but I’m not sure I really know what you are proposing to add or subtract.    Can you tell me specifically the wording you are proposing (or the final effect you want the wording to have?) 


> 
>> 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.

It is always good to include more options.  But dropping the basic one is not.  

Again, including other built in access approaches is always good.  

REQUIRING them — means everyone has to do all of them on everything.    Be sure that is possible.

ELIMINATING the basic one for one that is usable by less people - would be a significant reduction in access span.


Which/what are you proposing?


> 
>> 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.

Again - can you say what IT is?

Adding a new requirement in addition to keyboard interface access? 

IT above (saying that navigation doesnt have to all be possible from just the keyboard)  (that you said doesnt weaken it )   would eliminate access for all the people using the approaches I enumerated above. 

Or are you saying something different ?


> 
>> 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.

when you say OPTIONS — do you mean 

1) OPTION for the user (and therefore a requirement of the author?)

Then we are on the same page.  You are requiring BOTH the keyboard AND gesture? 
My questions then are 
how does the author provide gesture access to his content?
how does the author provide gesture access to his content on PCs?   

2) If you mean OPTION of the author — then the author would be able to have some navigation accessible via swipe and not keyboard and that would cut out all the people above again.
then it is not an option for the user — the author decides how the user much be able to access the content


Clearer now?

I can’t tell from this which one you are arguing for.   

thx

g



> 
> 
> -- 
> 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