See also: IRC log
<Kim> https://www.w3.org/2016/06/02-mobile-a11y-minutes.html
has the meeting password changed for webex or am i misremembering it?
(incidentally, could the password just be removed? not sure if there's any harm in having it without)
thank you
used uppercase rather than lowercase
i still don't know what the point of the webex thing actually is tbh
i.e. talking over phone line, chatting on irc...the actual webex client seems pointless
<scribe> scribe: patrick_h_lauke
[period at end of url isn't working]
[needs to be manually put in]
KP: under proposed SC there's a
new one. 2.6.1
... we took out force touch
decided to have discussion around force touch separately
instead of cramming it in here
we should wait until we have David's comments on this
has anybody not seen this last week?
Chriscm: not seen it
PL: i've not seen it either
KP: we took out force touch
thing to do is point this out to David
but go ahead and discuss force touch
Jeanne: i think there was more to discussion than just removing force touch
<Kim> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Discussion:_Touch_and_Force_Touch
need to make it clear that second one is the one we're proposing, as first one has glaring problem with exception
we also came up with two use cases for device manipulation:
shake to undo, where dev has to provide alternative; second one is step counter, which does NOT need an alternative, as it's not a user input
[discussion on which one REQUIRES alternative]
KW: we should have discussion on force touch, user requirements and problems
comments from WG are still going on, but created a wiki page already
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_and_Pointer_Guideline_-_WCAG_WG_Feedback
once survey closes, we'll make a survey to comment on comments
force touch https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Discussion:_Touch_and_Force_Touch - do we have a definition of force touch?
KP: no
KW: so we should start with force touch definition
Marc: isn't force touch apple-specific
PL: yes, as noted on wiki, we should use "pressure-sensitive touch", but there are stylus/pen with pressure sensitivity
KW: should we use pressure-sensitive input
PL: works for me
KW: do we have a definition then?
that it's via touch or stylus, that it's measuring pressure on the screen
[discussion on the fact that applications can react differently to interactions with a pencil/stylus vs interactions with a touch]
Chris: there will be situations where an application relies on the richness of force touch inputs; but there will be situations where it's reasonable to expect people to provide alternatives for
<jeanne> " except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)"
KP: there could be menus that require a pen that is pressure / tilt sensitive so that it can offer quick access to many menu options?
for ref: pressure, tilt https://w3c.github.io/pointerevents/#pointerevent-interface
KP: there are 100 levels of pressure and tilt, you can do amazing things, and it's unlikely that developers can provide an alternative that is keyboard accessible / non-pressure touch accessible
Jeanne: what other use cases have we got that are not complex?
KP: using pencil to highlight or not highlight text
PL: classic scenario (based on iOS) is simple tap/touch to activate, vs force touch to activate context menu/popup/peek&pop/auxiliary functionality/shortcuts
KP: but force touch is just a single value, not like pressure from pencil
<chriscm> Thanks Jeanne! Sorry, trying to listen as long as I can and pack for my flight at the same time :) I'm out guys!!!!
PL: no even on iOS touchscreen on latest iphones, pressure is a continuous measure (say from 0 to 1). iOS just decides that pressure up to a certain value is a tap, over that it's a force touch
KW: so what use cases have you captured so far?
KP: not captured use cases, but we've been talking about force touch going through levels
and a pencil...most applications now falling under exceptions
as patrick pointed out that applications now don't take advantage of more than 2 levels of pressure, there's potential for apps reacting to more steps/levels
issue is: what do we do with complicated stuff? drawing, music, etc?
are applications going to cut people out, and how can we deal with that?
KW: any more examples?
PL: you could use tilt (if we're widening the idea to tilt) as a joystick, using the position/angles of a stylus against the digitizer to control a flight simulator
KW: other scenario: using a pen to draw a signature?
PL: this would fall squarely under the definition of keyboard/path
KW: so given these scenarios, what are the challenges to the users
the simplest is users not being able to use things at all
Marc: would you include users that can't keep the pointer on the same spot?
KW: there could be users that don't know levels of pressure they're applying
patrick was actaully saying something...
have you unmuted me?
apologies for tapping away
<jeanne> q_
KP: i've used stylus and would say that using it you can do things amazingly well quickly
thing i fear most is users being shut out. even if making things FUNCTIONALLY equivalent (example of speech, where in theory yes user can say the names of keys)
PL: while i was muted, i talked
about how generally there are issues of users outright not
being able to use functionality (because they lack a
pressure-sensitive input), but more problematic users who have
the right input but lack dexterity (to hit, say, 20 different
pressure levels to enable 20 different options/effects, or to
keep their stylus static while applying ever increasing levels
of pressure, or tilting etc)
... are we now also including tilt/swivel/twist?
KW: isn't that device manipulation?
PL: i originally argued pressure IS device manipulation
i'd say there's a grey area particularly as we move to stylus/pencil that has pressure AND twist AND tilt etc
we can certainly say pressure/force touch is NOT device manipulation, but then for other sensors on the same input we can't say well those ARE part of device manipulation
so we'll need to perhaps look more broadly/re-categorise
KW: we're going to send out survey about this for next week, please look out for the email
KP: and if you can come up with more use cases please send them to list/add to wiki
RESOLUTION: further discussion needed to write clear definition of pressure-sensitive input, to come up with use cases (easy and hard ones). see survey that will come on mailing list
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/KP/KW/ Found Scribe: patrick_h_lauke Inferring ScribeNick: patrick_h_lauke Present: Kim patrick_h_lauke Kathy marcjohlic jeanne chriscm Regrets: Alistair Alan WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 09 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/09-mobile-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]