- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Thu, 23 Jun 2016 20:51:01 +0100
- To: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Cc: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
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: is there a very specific reason why "keyboard interface" https://www.w3.org/TR/WCAG20/#keybrd-interfacedef explicitly talks about "keystroke input"? 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). 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. 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. 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
Received on Thursday, 23 June 2016 19:51:31 UTC