Re: mobile-ACTION-53: Try and come up with some non-pointer/pointer/fancy touch definition

On 16/06/2016 16:33, Mobile Accessibility Task Force Issue Tracker wrote:
> mobile-ACTION-53: Try and come up with some non-pointer/pointer/fancy touch definition
>
> http://www.w3.org/WAI/GL/mobile-a11y-tf/track/actions/53

Apologies for sending this quite late/so close to our call, but: here's 
some of the thinking for this action:

I started looking at potentially useful bits of definition for initially 
differentiating "pointer input" from "non-pointer input" (before 
tackling the difference between "pointer" and "fancy pointer input with 
extra info like tilt/rotation/pressure").

Some initial bits:


# Pointer Events definition of "pointer" 
https://w3c.github.io/pointerevents/#glossary

"pointer: A hardware agnostic representation of input devices that can 
target a specific coordinate (or set of coordinates) on a screen, such 
as a mouse, pen, or touch contact.""


# in trying to talk about "non-pointer input" in the Pointer Events spec 
intro, I used the following language 
https://w3c.github.io/pointerevents/#intro

"keyboards or keyboard-like interfaces (for instance, a screenreader or 
similar assistive technology running on a touchscreen-only device, which 
allows users sequential navigation through focusable controls and elements)"


# WCAG 2.0's definition of "keyboard interface" 
https://www.w3.org/TR/WCAG20/#keybrd-interfacedef

"keyboard interface: interface used by software to obtain keystroke input
Note 1: A keyboard interface allows users to provide keystroke input to 
programs even if the native technology does not contain a keyboard.
Example: A touchscreen PDA has a keyboard interface built into its 
operating system as well as a connector for external keyboards. 
Applications on the PDA can use the interface to obtain keyboard input 
either from an external keyboard or from other applications that provide 
simulated keyboard output, such as handwriting interpreters or 
speech-to-text applications with "keyboard emulation" functionality.
Note 2: Operation of the application (or parts of the application) 
through a keyboard-operated mouse emulator, such as MouseKeys, does not 
qualify as operation through a keyboard interface because operation of 
the program is through its pointing device interface, not through its 
keyboard interface."



Some initial thoughts: the "letter" of the WCAG 2 definition of 
"keyboard interface" does not actually cover scenarios such as 
VoiceOver/TalkBack, where swipe gestures (left/right) move the focus 
sequentially through the page/app. Swiping, in these cases, does not 
send "keystroke input" - i.e. a swipe does not emulate a keyboard and 
send a faked "TAB" or "SHIFT+TAB" keystroke/keyboard event - it simply 
moves the focus sequentially (and, as an aside, in most cases it does 
not actually trigger a "focus" event/state on the element which receives 
focus, at least in the case of browsers/web content - see 
https://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-events 
and 
https://patrickhlauke.github.io/touch/tests/results/#desktop-touchscreen-assistive-technology-events).

Now, WCAG 2.0 does actually have a definition for "navigated 
sequentially" https://www.w3.org/TR/WCAG20/#nav-seqdef

"navigated sequentially: navigated in the order defined for advancing 
focus (from one element to the next) using a keyboard interface"


but, because this cross-references the (incomplete, as discussed above) 
definition of keyboard interface, this definition also doesn't currently 
apply to VoiceOver/TalkBack and swipe gestures.

In principle, the idea behind "sequential navigation" is probably what 
we're after in the VO/TB swipe navigation scenario: a way of navigating 
that advances focus. If the problematic "keyboard interface" definition 
were fixed/expanded, this definition would actually be useful as a 
starting point.
What is perhaps missing from this particular definition as well is the 
idea of what I'd call "two-step" navigation/activation - where focusing 
and activating/actioning an element are two separate steps. I have vague 
memories that we may have talked about this at some point 
already...anybody able to refresh my mind on that?


Further thoughts/recap:

- the definition of "keyboard interface" in WCAG 2.0 is flawed/skewed 
towards actual keyboards / inputs that emulate/act as a keyboard (i.e. 
that fire keystroke events), and it does not cover touchscreen+AT scenarios

- however, the principles/SCs in WCAG 2.0 relating to keyboard (2.1.1 
Keyboard, 2.1.2 No Keyboard Trap, 2.1.3 Keyboard (no exception)) are in 
fact what I believe we want to achieve for touchscreen+AT scenarios; 
initially, this was attempted by going down the path of creating new 
SCs, but I think it was resolved that we should instead try to 
extend/fix the "upstream" WCAG 2.x definition (see for instance 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Issues_in_WCAG_2.2.1_keyboard_trap). 
I *think* what we want to basically say instead of keyboard is more akin 
to keyboard/keyboard-like/"sequential navigation input 
mechanism"/non-pointer input mechanism.

- the Pointer Events spec definition of "pointer" contains a potentially 
good initial definition of what is a pointer input:
"[an] input device that can target a specific coordinate (or set of 
coordinates) on a screen, such as a mouse, pen, or touch contact."; 
conversely, a non-pointer input mechanism would be...anything else, 
including a traditional keyboard, a keyboard-like interface (such as 
switch access input), or a sequential navigation mechanism such as in 
the touchscreen+AT swipe scenario

Question now is: is there any mileage in looking at the current WCAG 2.0 
"Guideline 2.1 Keyboard Accessible: Make all functionality available 
from a keyboard" and seeing if that can easily be 
monkey-patched/extended/generalised to the above? Happy to take a stab 
at this, but before doing any work I want to be sure if this would then 
stand a chance to get into WCAG 2.1 ? I've lost track of the 
politics/plan of action (whether we can only "extend" WCAG 2.0, or 
whether it's actually open to the possibility of modifying core parts of 
WCAG for a 2.1 / WCAG.next update).

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 14:04:28 UTC