See also: IRC log
<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
<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
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) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Present: patrick_h_lauke Alistair Kim Kathy marcjohlic Alan jon_avila Jeanne Michael Regrets: Henny Detlev 1 Alan Found Date: 19 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/19-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]