<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

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: