W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

09 Jun 2016

See also: IRC log

Attendees

Present
Kim, patrick_h_lauke, Kathy, marcjohlic, jeanne, chriscm
Regrets
Alistair, Alan
Chair
SV_MEETING_CHAIR
Scribe
patrick_h_lauke

Contents


<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)

<Kim> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Guideline_2.6:_Make_it_easier_to_use_the_physical_features_of_the_phone.

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

<Kim> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Guideline_2.6:_Make_it_easier_to_use_the_physical_features_of_the_phone.

<scribe> scribe: patrick_h_lauke

Finish 2.6.1 https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Guideline_2.6:_Make_it_easier_to_use_the_physical_features_of_the_phone.

[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

Summary of Action Items

Summary of Resolutions

  1. 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
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/09 16:06:59 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]