- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 19 May 2016 12:11:57 -0400
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <573DE5CD.3060300@redstartsystems.com>
*MATF Minutes 19 May 2016 link:
*https://www.w3.org/2016/05/19-mobile-a11y-minutes.html
*
Text of minutes:*
Mobile Accessibility Task Force Teleconference
19 May 2016
See also: IRC log <http://www.w3.org/2016/05/19-mobile-a11y-irc>
Attendees
Present
patrick_h_lauke, Alistair, Kim, Kathy, marcjohlic, Alan, jon_avila,
Jeanne, Michael
Regrets
Henny, Detlev, 1, Alan
Chair
Kathleen_Wahlbin
Scribe
Kim
Contents
* Topics <https://www.w3.org/2016/05/19-mobile-a11y-minutes.html#agenda>
1. Finalizing Guideline 3.4 - Orientation
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4.1
<https://www.w3.org/2016/05/19-mobile-a11y-minutes.html#item01>
* Summary of Action Items
<https://www.w3.org/2016/05/19-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2016/05/19-mobile-a11y-minutes.html#ResolutionSummary>
------------------------------------------------------------------------
<patrick_h_lauke> (just dialing in)
<patrick_h_lauke> (i have a fairly hard stop at 10mins to the hour)
<Alan_smith> Alan is on call now and irc
<Kathy>
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4.1
Finalizing Guideline 3.4 - Orientation
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4.1
<patrick_h_lauke> i looked over it, and it LGTM
Kathy: we've gone through a lot of iterations on this -- I think were in
a good spot. Any further comments or concerns now that we've had a week
to mull it over
Marc: wiki page number
Kathy: should all be 3.4.1
Alan: looks great
Kathy: we've been trying to nail down the use cases
<Kathy> https://w3c.github.io/Mobile-A11y-Extension/
David to correct numbering to 3.4.1
<Kathy> Guideline 2.6: Make it easier to use the physical features of
the phone. Intent of Guideline 2.6 [Proposed text for Understanding]
2.6.1 [Proposed New MOBILE Success Criteria] Device manipulation: When
device manipulation gestures are provided, touch and keyboard operable
alternative control options are available. (Level AA)
David making new wiki page for 2.6
Kathy: general gist is with mobile devices we have a number of features
in AT built into the device which allows you to do customization so you
can see things in the way that you want to see them. We were talking
about making it user to use the physical features of the phone. We had
one success criteria under here, could probably add others depending on
the use cases. Things available via...
... device manipulation like tilting make sure these are available for
something else -- keyboard or keyboard alternative.
... opening up for discussion -- what are some initial thoughts as we go
back and read this as far as what you think is important or even start
talking about use cases -- things that are important for the users as
far as physical features that are part of the device or just even
talking about device manipulation in general
Patrick: Related to this 3-D touch would fall into this as well. Not
every iOS device has pressure sensitive. The Apple advice is make sure
optional -- there is some other way to do it besides 3-D touch
Kathy: is three touch device manipulation: reading definition of device
manipulation
Patrick: where would 3-D touch fall under in that place -- it
conceptually seems to fit but doesn't fit that descriptionof device
manipulation
Kathy: if we were going to create a different success criteria for 3-D
touch what would it be
David: do we really want to go in that direction? Can we not just
definitely have their as far as device manipulation instead of a whole
new success criteria for 3-D touch
Patrick: just suggesting to keep it separate while we figure out what
the use cases are
Kathy: let's talk about the different use cases -- device manipulation
and 3-D touch. What are the challenges with each
... what are the requirements and challenges for user that we are trying
to solve
Patrick: android is also emulating 3-D touch by just having the user
wait for certain amounts of time on the icon
Chris: I don't think that's the same thing
iOS has long press as well
Patrick: 3-D touch is device specific. The use apps make of it is the
equivalent of a right mouse button
<patrick_h_lauke> 3D touch depends on having the sensor/touchscreen that
supports it
Kathy: but online is users are not going to be able to do 3-D touch --
not all devices are going to have it. But online is because some users
can't do it we need to have an alternative available which doesn't rely
only on 3-D touch. Any other use cases with 3-D touch
Jon: galaxy edge -- edge screen specific -- with this fall into that
category as well -- any other devices?
Chris: if you can use a touchscreen you can use the edge -- nothing
special about it really
Kathy: we do need to start talking about all of these things that are
available today
Patrick: I can see the point that if you can't use the touchscreen in
your reliant on sequential navigation -- screen reader for instance --
web reader is specifically looking for edge specific gesture things then
you won't be able to trigger those either but that might for more with
the actual gesture stuff rather than this area which is more about any
new sensors or physical buttons or...
... things oof that nature
Chris: a lot of the software requirements for those which fit under
other regulations OS and not necessarily the app developers
Kathy: same issue with device manipulation -- some users may not be able
to manipulate the device so we can't do it is the only means -- what are
other things to think about with device manipulation
Patrick: also how do you differentiate three touch from ordinary touch
... criteria touching different places, 3-D touch includes all of those
things
... if you're going to try and carve it out in some way you need to be
able to differentiate it from an ordinary touch. As I understand it it's
just the pressure you apply to it but the rest of the stuff that has to
do with touch automatically covers
<patrick_h_lauke> 3D touch (a really horrible name that apple came up
with, btw) is basically: it has a pressure-sensitive touchscreen, and
passes on pressure
<Alan_smith> Alan dropping call due to business meeting.
<patrick_h_lauke> so we're concerned with the "actions etc that trigger
based on pressure"
Chris: binary event -- even along touch is still the same binary event
it's just that you've been doing this other binary for a long time and
it triggers. All digital either it happens or iit's not. Define ssimple
touch which is this binary event oor something else -- and the something
else is what we are discussing
David: you are saying analog event -- are you saying whole bunch of
digital events, more pressure different event.
<patrick_h_lauke> you get pressure info as a float value between 0 and 1
Chris: can be thought of as a more analog type of experience. Either
happening or not. But whole range. represented by 54 bit integer.
Probably not whole range with significant
Patrick: I don't think it matters so much in terms of the granularity.
In terms of the specifications float value between zero and one.
Potentially fairly granular value that you can potentially get back to
pending on hardware itself.
... ddifference between 3-D touch -- horrible marketing name it's really
pressure touch -- and regular touch is essentially it needs a particular
sensor -- pressure sensitive touchscreen and that the Apple content will
react to whatever that pressure value is. That's what we are trying to
get to. You need a specific capability on your device -- could be an
accelerometer, extra...
... set of...
... buttons or something else on the device itself and having the
ability to use that or not use that and that application should cater to
both situations where the user can use it or can't use it. either
because it's not there or because the user for their own reason can't use it
... gesture stuff?
Marc: we only have one device using this -- do we wait until more, or
chance that Apple might not continue to use it
Patrick: if it's possible to word this part to include things like 3-D
touch or specific peripherals or sensors or device capabilities through
buttons on the device then we are probably covered regardless of whether
Apple will be the only ones or if next week android comes out with its
own equivalent or slightly different way of interacting on the
touchscreen with pressure
Kathy: we need to think of what will happen in the future
Marc: pressure sensitive is 3-D touch
Patrick: pressure sensitive touchscreens just to make it less branded
... I think conceptually it wouldn't seem completely out of place to
just extend the definition and then it wouldn't require any different
pass/fail or techniques are suggested methods or anything like that
... we still haven't included other points like gesture control
specifically addressing that in their own way but the high-level context
of you shouldn't expect it so make sure the user has another way
Kim: all input is similar -- high-level context of make sure there's
another way
Patrick: the high-level context works for 3-D touch.
<Kathy> Moving or controlling the device with hands, body or machine.
Device manipulation includes other methods of controling input to the
mobile device outside of using the touch screen. This includes: pressing
a physical button on the device, shaking, holding, proximity, touch,
walking, angle of holding, input via the accelerometer etc. Gestures to
the camera and voice input to the microphone are addressed separately.
<patrick_h_lauke> looking at the definition though, it talks about
"specific peripherals or sensors"
David: pressure sensitive -- shoehorned in if we try to put it in here.
Separate SC on force -- rather than manipulating actually moving.
Patrick: definition talks about specific peripherals, touchscreen with
sensors would fall under that
Kathy: right now we have pressing a button, shaking, holding, angle of
input. We could put pressure on the screen. I think that's the type of
manipulation is the amount of pressure.
Jon: there are other devices that support pressure-- pens. 3-D touch is
not the only thing out there that doesn't.
Patrick: Wacom tablet on a tablet even supports pressure
<davidmacdonald> manipulatedmanipulating 1 : to operate, use, or move
with the hands or by mechanical means <She learned to manipulate the
levers of the machine.>
Patrick: similarly on the OSX side, latest generation MacBook pros
pressure sensitive trackpad -- force touch. Has nothing to do with
touchscreens
<Kathy> Moving or controlling the device with hands, body or machine.
Device manipulation includes other methods of controlling input to the
mobile device outside of using the touch screen. This includes: pressure
touch sensors, pressing a physical button on the device, shaking,
holding, proximity, touch, walking, angle of holding, input via the
accelerometer etc. Gestures to the camera and voice input to the
microphone are addressed separately.
Patrick: different types of force touch and that concept of making sure
authors don't code assuming users have it. Same concept of not assuming
an accelerometer
<patrick_h_lauke> sensors: accelerometers, pressure sensors...
David: next question is are we running the risk of having another 1.3.1
where half of everyone's reports is on one success criteria. I think we
can put it in here.
Chris: speaking out loud -- I would say no.. At some point you have to
acknowledge that if somebody can't manipulate a device enough they need
to use a different A-T. And at the point where somebody can pick up a
device and use the touchscreen if they can't also respond to the type of
touch -- we are essentially talking about variations on the touchscreen.
And if you can't use the touchscreen...
... the way the touchscreen was designed to be used -- the developers
take advantage of all those features. Then you should be using some
other type of A-T. And at that point you have to deal with that and say
I just can't use this device I have to use it an alternative way..
That's my thoughts on it
David: I'm nervous about that. I would hate to see it get away from them.
Chris: that's the point, the blind community uses another AT. That's a
requirement to the AT developer not the content. Your AT should not
depend on these features of these touchscreens, but when were talking
about shared requirements for when the AT is on are not on that's a
different realm. I completely agree with you if we are saying that the
A-T is on. OS/AT developer content
<patrick_h_lauke> so we leave it all up to the AT? content/apps that
rely on accelerometer to tilt/shake...should users just use an AT that
simulates this?
David: question I'm asking is I think we can justify putting it into
this success criterion, but should we or break it out to a different
success criterion. It sounds like we have to backtrack and get
uniformity on whether it's an important requirement to have.
... exception -- keyboard manipulation -- everything needs to be
accessible via keyboard except if a line between two points is not a
straight line. We wanted to make sure that people making drawing
programs would not have to turn them into Etch-a-Sketch is. We have an
exception on that. I wonder if there's an exception we can put on this.
Touch sensitive unless it's a granular type of...
... thing that's necessary to the application
<Zakim> jeanne, you wanted to say that it should be considered for a
user agent guideline and not a content guideline.
Jeanne: it seems like this is more what we want to be saving for
whatever were going to be doing for the devices and the user agents. I
think what David was just saying about having an exception on that maybe
-- if we put it in WCAG the way it is now it's going to be interpreted
as the author's responsibility. There's clearly an important need to
make sure that anything that can be done...
... with the device can be done with a keyboard, but I just can't see
making that the responsibilities of the authors.
David: right now it's already their responsibility
<davidmacdonald> Functions that rely on pressure sensitivity can be
operated without touch sensitivity except where there are more than xxx
degrees of pressure ...
Patrick: in the interim though if we say it's just the IT that has to
support this is potentially a slippery slope.. I can make an app that
reacts to shaking the device or tilting it and if the user can't do
that, well that's the problem of iOS that they don't have some built-in
function that should be like shaking or tilting, and in the in term
needs to be supported by authors. Once it's...
... there that can be a technique -- method is available to authors, but
there still considerations of what if they haven't got that or what if
the A-T should be doing that but doesn't
Jon: when can we draw the line -- assistive touch does shake on iOS --
iOS already has it
<chriscm> +1 excellent comment!
<patrick_h_lauke> afraid i need to jump out of the call now...but good
discussion, though it goes right back to the fundamentals of what we can
and can't ask authors to do vs the reality of what user agents do or
don't (regardless of UAAG or not)
<patrick_h_lauke> but related: why require authors to cater for
different orientations and not locking orientation? it should just be
the user agent that allows you to rotate/not rotate the orientation?
with the reasoning we can obviate the need for anything...
Kim: Tower of Babel danger in having many user agents doing things
differently rather than pushing things to platform or browser. This is
very apparent with speech input
<patrick_h_lauke> +1 to what david's saying (re "mechanism is available")
David: we can manage that with a method is available language
Jeanne: but as soon as we do that we let the browsers off the hook -- if
the browsers don't have to because we keg says the author is
responsible. I think we have to be very careful about that. It's a good
short-term solution to improving accessibility but I don't think it
works in the long run
Kathy: do you think it's okay to not accommodate so we can force user agents
... that's the problem -- other than arguing the fact that the users
need to there's no law there is no anything to force the user agents to
do anything
Chris: just relying on their own goodwill and common sense to say this
is the way it should happen
Jeanne: planning to do for WCAG 3 they are talking about including UAAG.
One document, success criteria for platform, user agent, author -- see
them all next to each other, that context
... at first we were keeping a list of what the user agents should do --
I think that's still a good idea
David: I love a holistic approach.. Right now we seem to have legal
power behind WCAG and nothing much else
<chriscm> Sorry everybody, I have to hop off. Great discussion!
David: maybe eventually we take big chunks and move over to the user
agent. Our task is to brainstorm success criteria -- bring it back to
the larger group.
Jeanne: there isn't legal force behind 2.1
David: there isn't, but there's momentum
Jeanne: there is, momentum, and branding. But I don't want to perpetuate
the last eight years with the browsers
... I want us to have a little bit of caution on this one
Kathy: some of it is on the authoring side -- suggestion on what this
should be
Jeanne: write the part on the authoring side, put a note in the wiki
that says this should be addressed more on the user agent side, and here
are some of the things that we talked about that need to be covered by
the user agent, an alternative means for shaking, alternative means for
exterior buttons, all the things that we've been talking about. And that
waits in our document, we won't lose...
... it. And maybe it'll be starting to give fair warning to people that
we are moving in that direction
David: don't want to lose it -- put in understanding document and say we
expect...
... is there anybody who thinks we shouldn't be developing into the
world of pressure sensitive devices
Kathy: I think were all in agreement there. And I agree with Jeanne. I
like putting it in the understanding document.
<jon_avila> I think we should use the wording like SC 2.1.1 "is operable
through a keyboard interface "
Michael: this pressure sensitive issue sounds like a really interesting
one. I do think it's within the realm of this group to look at it. I
think it's an example of how technology absolution is continually
creating new challenges. If there's something we can do in the short
term to address pressure sensitive because we know what the solutions
are I'm all for it but I think it's going to...
... be a larger issue. If we try to have guidelines that have a
requirement for every single technology or user interface I think will
find it becomes unmanageable. I'd like to think in terms of how we can
provide for general but so easily understandable guidelines.. I think we
have to look at that bigger picture as well
<jon_avila> I'd say it's already covered as well under SC 2.1.1
<davidmacdonald>
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Guideline_2.6:_Make_it_easier_to_use_the_physical_features_of_the_phone.#Proposed_2.6
<davidmacdonald> webex closed
<Kathy> I guess that is the end
Kathy: We're out of time. Great point. I think if we all thinking on
this and we can continue the conversation next week. URL of wiki page.
<jon_avila> ok -- that was fast
WebEx just automatically shut down the phone conversation
<Kathy> talk to you all next week.... continue to think over the next
week and add info to the wiki or over email
<jon_avila> without requiring specific timings for individual
keystrokes, except where the underlying function requires input that
depends on the pressure of the user's movement and not just the touch
points.
Hmm -- not enough time looking at use cases before WebEx implemented
that new feature
Summary of Action Items
Summary of Resolutions
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/05/19 16:06:47 $
------------------------------------------------------------------------
___________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>
www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly
Blog: Patch on Speech
+Kim Patch
@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 19 May 2016 16:12:28 UTC