Re: MATF Minutes 14 April 2016

Just some tiny observations from the sidelines here (not having followed 
a lot of the intervening discussions on list, apologies if this retreads 
ground):

On 14/04/2016 17:14, Kim Patch wrote:
> *MATF Minutes 14 April 2016 link: *
> https://www.w3.org/2016/04/14-mobile-a11y-minutes.html


> Detlev: BBC guidelines more specific – touch start, only if inside
> target will fire. Use the support of the screen to move the finger
> inside the target wouldn't be covered by BBC.

Worth noting that BBC guidelines are just that...guidelines specific to 
the BBC They can be seen as good practice, but they were not written (or 
intended to be seen as) universal. (incidentally, had a lengthy to- and 
fro- discussion with Jamie Knight from the BBC around this topic 
https://twitter.com/JamieKnight/status/719816178013757440)

> David: previous language selection and activation are independent
[...]
> Chris: what if I say it like this instead of touchup activation, what if
> I say don't activate on hover
>
> David: hover is a mouse word – I don't hover when I'm touching the
> screen. Equating the word hover when my finger is in contact with the
> screen but hasn't left it?
>
> Chris: yes. It's a language in both native APIs for android and iOS
> ... the event that gets sent when your finger enters the screen is hover
> ... defining that would be good
>
> David: we actually want to focus on when the finger leaves and comes up
> rather than what not to do when it goes down

Maybe a bit vague, but what about making the distinction between 
"moving" to a control and "activating" it? And then in understanding 
explain that "moving" can mean hovering over it in case of a 
mouse/stylus, of placing a finger down onto a touchscreen surface in 
case of touch ? Though for touch, this would then still 
intersect/overlap with what a long-press is...

> Chris: why are we concerned about a mouse – any trouble users have with
> mouse should be covered by WCAG generally.
>
> David: whole touch and pointer event is a bucket
>
> Chris: in that case some of the things I said would only apply to
> mobile/touch users interacting with a touchscreen
 >
> Detlev: touch specific language is good with techniques but success
> criterion should be more general
> ... so general usability issue or does it need to be inside WCAG because
> it supports people who need accessibility in some way
>
> David: when you first put your hand on it it's a hover state.
> ... that's the language to use. We've been using selection, and some of
> us had a little trouble with the word selection. Do we want to go with
> the word hover or does that seem technology specific?
>
> Detlev: however doesn't cover mouse because mousedown
>
> Kathy: what about the up event versus the down event?
>
> David: up event activation
>
> Detlev: we could try that
>
> Kim: I like up/down – clear language

On the topic of activating on up rather than down: note that there are 
scenarios where it is preferable to activate on down - for instance, in 
the case of immediate controls for games (think a space shooter or 
whatever, where you want to fire the ship cannon when the user touches 
down/touchstart, rather than only firing once user lifts the finger). 
There may be other scenarios, but my main point: I'd be careful making 
activations on touchstart/finger down on the screen a hard failure when 
there are in fact legitimate uses for it.

> David: editing in wiki to up event activation…
> ... is up event too wide – selection events
>
> Chris: easy to see – if selection event and focus event are the same
> thing, you have broken this criteria
>
> Kathy: there's a way to separate activation from non-activation events
> ... or we could add that to the understanding document
>
> Detlev: wording of understanding – may be Touch specific things in there
>
> David: fixing, touch and mouse events
>
> Detlev: map more specific terms to our up event thing
>
> Chris: I was trying to think that we could just call it control
> activation instead of up event activation
>
> David: this really is about the up event
>
> Chris: one of the things that would make it completely objectively
> defendable is making the criteria about separating those events and in
> the understanding and the failures lift up the touch event as the best
> practice
>
> David: understanding and failure techniques are to help people
> understand what we are getting at but we can't really have success
> criteria that doesn't say what we really mean. Like saying you can
> separate the success criteria, then they could just do it on the down
> event. it's not wrong, but then you just have to make sure there's
> another way to do things. In a bizarre situation like say...
> ... it's a piano keyboard they would have to have a little switch on it
> that could say you can come up from it.
> ... if we don't go on a touchup activation I don't think we have a lot
> to hang on. The larger community says we can't do that – but I just
> don't see that you can do it any other way than touchup

Rather than mandating that apps provide their own switch or something 
(and the whole discussion - already touched on previously on this list - 
about not being able to mandate that each app/site provide their own 
customisation/preferences), the technical way to solve this is for devs 
to listen to BOTH touchstart/the down event AND the more generic, 
input-agnostic "click"/generic activation event, and to de-dupe if 
necessary (e.g. suppress compatibility mouse events and click in the 
case of touch events with preventDefault/cancelling the event).

As long as devs also cover the generic activation event, there is then 
scope for OS/browsers themselves to provide user-specific 
customisation/preference options for how the user wants to fire 
activation/click, without the developer having to try and 
accommodate/provide options for different users.

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 Saturday, 16 April 2016 21:14:46 UTC