- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Thu, 9 Jun 2016 17:12:56 +0100
- To: public-mobile-a11y-tf@w3.org
Hi All, draft minutes from the last MATF call are available at https://www.w3.org/2016/06/09-mobile-a11y-minutes.html and copied below. If you have any comments, corrections, etc., please reply to this email by 14 June. In the absence of any changes, these minutes will be considered approved. - 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 Topics 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. Summary of Action Items Summary of Resolutions <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 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] -- 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, 9 June 2016 16:13:20 UTC