Re: AW: Rough draft of some success criteria for a extension guideline "Touch accessible"

On 27/07/2015 22:16, Detlev Fischer wrote:
> Hi Patrick, I didn't intend this first draft to be restricted to
> touch ony devices - just capturing that input mode‎. It's certainly
> good to capture input commonalities where they exist (e.g., activate
> elements on touchend/mouseup)

Or, even better, just relying on the high-level focus/blur/click ones 
(though even for focus/blur, most touch AT don't fire them when you'd 
expect them - see 
http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-events 
and particularly 
http://patrickhlauke.github.io/touch/tests/results/#desktop-touchscreen-assistive-technology-events 
where none of the tested touchscreen AT trigger a focus when moving to a 
control)

> - but then there are touch-specific
> things, not just touch target size as mentioned by Alan, but also
> touch gestures without mouse equivalent. Swiping - split-tapping -
> long presses - rotate gestures - cursed L-shaped gestures, etc.

It's probably worth being careful about distinguishing between gestures 
that the *system / AT* provides, and which are then translated into 
high-level events (e.g. swiping left/right which a mobile AT will 
interpret itself and move the focus accordingly) and gestures that are 
directly handled via JavaScript (with touch and pointer events specific 
code) - also keeping in mind that the latter can't be done by default 
when using a touchscreen AT unless the user explicitly triggers some 
form of gesture passthrough.

For the former, the fact that the focus is moved sequentially using a 
swipe left/right rather than a TAB/SHIFT+TAB does not cause any new 
issues not covered, IMHO, by the existing keyboard-specific SCs if 
instead of keyboard it talked in more input agnostic terms. Same for not 
trapping focus etc.

For the latter, though, I agree that this would be touch (not mobile 
though) specific...and advice should be given that custom gestures may 
be difficult/impossible to even trigger for certain users (even for 
single touch gestures, and even more so for multitouch ones).

> As
> changing core WCAG is not on the table ATM I think it makes sense
> drafting extensions and see whether they can make sense.

In my view, that's unfortunate...and something that should be fed back 
up the chain, as the risk here is that instead of smoothing out the 
problems caused by having input-specific advice enshrined in the core 
spec (i.e. the emphasis on "keyboard"), we'd end up simply piling extra 
input modalities on top (including the commonalities that don't require 
any input-specific consideration beyond using words other than "keyboard").

Sorry, my barging in here and delivering my Joyce-ian streams of 
consciousness may come across a bit confrontational. It's not intended. 
Just want to ensure that we don't end up building a whole new silo of 
extended SCs that are nominally "for touch/mobile", when in fact a lot 
of it would be better fixed at source.

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 Monday, 27 July 2015 21:37:05 UTC