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

gregg

> On Jun 23, 2016, at 3:51 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> Hi Gregg,
> 
> as part of our work in the Mobile A11y TF, I started looking at some aspects of existing glossary definitions as they relate to input, to see where touchscreen, touchscreen with AT, and similar scenarios can be included/need to be harmonized.
> 
> One aspect that I'd like to quiz you about (David McDonald seemed to remember you had strong feelings about this specific wording at the time) is this:

Not feelings really…    but sometimes concerns     sometimes opinions  or thoughts.

> is there a very specific reason why "keyboard interface" https://www.w3.org/TR/WCAG20/#keybrd-interfacedef explicitly talks about "keystroke input”?

The term was used because we can’t say  “text  input” since arrow keys, tab etc are not text.     So best term the group could come up with “keystrokes” to indicate it could be done from a keyboard or keyboard interface.. 


>  Main reason is that for many common scenarios for touchscreen with AT - for instance, VoiceOver on an iPhone - swiping left/right achieves "sequential navigation" (in the sense of https://www.w3.org/TR/WCAG20/#nav-seqdef), but it does NOT fire keystrokes (i.e. no "faked" TAB/SHIFT+TAB key events, or cursor/arrow left/right key events, are exposed...but the VoiceOver focus IS moved sequentially).

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. 


> The spirit, and actual SCs, for 2.1 would apply to this mode of sequential navigation on touchscreen+AT devices, but the "keystroke input" part obviously precludes this.

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

I’m not sure what you are suggesting here for 2.1.   
That all navigation MUST be doable with gestures? 
That navigation by gesture should be equated with (satisfy ) the 2.0 requirement for all use via keyboard interface?   (this would be a roll-back of 2.0 and permit (require of the user) something that that SC was specifically trying to avoid  (that user have any ability other than sending “keystrokes” through a keyboard interface. 

> 
> In short, just trying to understand if I'm missing a very specific reason for the exact "keystroke" wording, or if there's potential (maybe for future versions of WCAG) to modify the definition slightly to also make any 2.1 related SCs also cover touchscreen+AT without the need for unnecessary duplication of intents.
> 

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. 


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. 

does that help? 


If unclear or you think I dropped a thought — or you see a fault in my or the groups logic on this — ping back.  

thx
g




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