15:49:44 RRSAgent has joined #mobile-a11y 15:49:44 logging to http://www.w3.org/2016/01/21-mobile-a11y-irc 15:49:46 RRSAgent, make logs public 15:49:46 Zakim has joined #mobile-a11y 15:49:48 Zakim, this will be WAI_MATF 15:49:48 I do not see a conference matching that name scheduled within the next hour, trackbot 15:49:49 Meeting: Mobile Accessibility Task Force Teleconference 15:49:50 Date: 21 January 2016 15:50:01 chair: Kathleen_Wahlbin 15:50:58 agenda+ Review understanding document 15:51:00 agenda+ Review assignments http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments 15:51:01 agenda+ Continue to Review draft of Mobile Accessibility Extension 15:51:03 agenda+ Next steps – next meeting January 21 15:55:46 clear agenda 15:56:29 Detlev has joined #mobile-a11y 15:56:53 agenda+ Mobile Accessibility Extension > Touch & Pointer - https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer NOTE: we have added some text in for understanding document. 15:56:54 agenda+ Technique Assignments 15:56:56 agenda+ Next steps – next meeting January 21 16:03:46 Kathy has joined #mobile-a11y 16:04:15 agarrison has joined #mobile-a11y 16:05:53 Regrets+ Henny, Alan, Marc 16:06:54 present+ jeanne 16:06:58 present +Kathy 16:07:02 Present+ Kim 16:07:08 present+ 16:07:31 present+ alistair 16:07:55 Kathy: we've been working at getting additional language into new proposed guideline – touch and pointer. 16:08:29 Kathy: I've started understanding – done first couple sections, some of it was language from our document 16:08:39 David has joined #mobile-a11y 16:08:50 present + 16:09:06 Kathy: if you see things that are not clear or we need more detail on. I want to keep it concise but don't want to miss information either 16:09:09 https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer 16:09:38 TOPIC: 2.5, 2.1.1 Understanding 16:11:33 David: add don't step on existing swipes and stuff 16:11:44 Kathy: it's going to be different for each OS 16:12:24 David: can be specific, but be familiar with your technologies platform system controls, and can provide a link common swipes and taps for iOS and Android 16:12:53 David: want to put it in section for related resources 16:12:56 q+ 16:13:39 confusion about numbers – automatic numbering is not yet working properly 16:13:52 Be famililar with your platform's system controls and standards for assistive technology. Use the system controls supported by the platform first. 16:15:24 Be famililar with your platform's system controls and standards for assistive technology. Use the system controls supported by the platform first and don't overwrite the standard gestures of the platform. 16:15:46 q+ 16:16:33 Don't use a common gesture for a purpose that is not common. 16:16:34 David: advice in iOS and android is that you don't use a common gesture for something that's not common – I'll look for that section 16:17:21 Kathy: in further resources if we are linking to AT gestures do we only link to the official ones or for example we have this really nice graphical gesture list sheet, would it be okay to link out to those or should we just stick to Apple and Android 16:17:45 David: best to go to the manufacturers who are doing it because that advice may change over time. We have the ability to do either, but in general the consensus has been to point to stuff that's as close to the source as possible 16:18:42 Jeanne: and be prepared for link rot – Apple moves their accessibility information regularly, as does Gnu 16:19:29 Alistair: under intent guideline 2.5 second paragraph – all users can use the device – too hopeful, I would strike 16:19:47 q- 16:19:49 https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/InteractivityInput.html 16:20:18 David: guidelines for custom gestures 16:21:49 Detlev: equivalent to deleting by swiping for example? 16:23:19 Alistair: Can't use the functionality because it's been used up by voice over. That's a slightly different twist to the way this is structured 16:24:04 Detlev: can't disable two finger or three finger swiping 16:24:37 David: add these two examples into the understanding: for instance, if the user overrides a double tap, then the voice over user won't get access to that. 16:24:51 David: as long as we say for example, good language to use in the understanding document 16:25:38 Kathy: if developers do a custom gesture with a double tap and there's a conflict between screenreader double tap and that defined by the program… 16:26:07 Detlev: I like the language that screenreader takes away – you have to find another way to do it 16:26:38 Kathy: under 2.5.1 16:29:01 https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/InteractivityInput.html https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html https://support.google.com/accessibility/android/answer/6151827?hl=en 16:29:28 http://developer.android.com/training/gestures/index.html 16:29:58 http://www.windowsphone.com/en-us/how-to/wp7/start/gestures-flick-pan-and-stretch 16:30:36 For example, if a developer assigns a double tap as a custom gesture, as the only way to complete an action, a user who is blind using VoiceOver will not have access to that action because VoiceOver reserves the double tap to select an item. the only 16:31:02 Kathy: any other resources for accessibility/touch 16:31:19 https://www.microsoft.com/en/mobile/accessibility/use-narrator-on-my-phone/ 16:32:08 Detlev: as all these are built out issue, for example Google talk back presumably holds onto the same gestures as talkback, but I presume over time this is going to be a very big list to be able to maintain 16:33:07 Kathy: just the manufacturers, Apple, Google, Windows, blackberry, not looking at Samsung etc. But it is a good point – Samsung is a pretty big manufacture and is used a lot, so if they have changed gestures and added gestures into what talkback does natively… 16:33:39 http://downloadcenter.samsung.com/content/UM/201503/20150303094626458/SM-G920F_UM_EU_Lollipop_Eng_Rev.1.0_150302.pdf 16:33:45 David: historically there have only been a few winners and the emerging winners, if we stay on top of those, we have to be practical to a certain extent. If we see something getting traction, we can add 16:34:07 Alistair: resources on the wiki page 16:34:16 Kathy: this is the manual 16:34:50 Detlev: open question whether resources for Blackberry will be useful – switching to Android 16:36:54 Kathy: we have a good set of resources – 2 each for Windows, android, iOS, and then one for Samsung. Should leave out blackberry since they are switching to android 16:37:32 Continue on example 1: The developer can avoid this problem by avoiding to chose a common gesture to do an unexpected action or by providing an additional way to complete the action with touch in a way that doesn't interfere with VoiceOver gestures. 16:37:58 Detlev: blackberry for blind user not a nice experience at all the last time I checked, also crashed easily 16:38:19 Kathy: any other changes 2.5.1 section 16:39:54 Kathy: I'll continue going through the success criteria that we have and write up the other understanding ssections for the sections that we've been completed – to 2.5.4. Also need to add 2.5.4 new wording from last meeting 16:40:35 Kathy: might be a good test to see what happens on android if you try to do something with a double tap, wondering if Patrick has examples 16:41:22 Example 2: If a developer assigns a swipe right as the only way to open a menu, the VoiceOver user will not be able to do that action, because VoiceOver overtakes the right swipe as a way to move from element to element. In order to avoid this problem, the developer could ensure there is a mobile menu button which works with touch as another way to bring up the menu. 16:43:25 Just change overtakes to takes over 16:44:36 If a developer assigns a swipe right as the only way to open a menu, the VoiceOver user will not be able to do that action, because VoiceOver takes over the right swipe as a way to move from element to element. To avoid this problem, the developer could ensure there is a mobile menu button that works with touch as another way to bring up the menu. 16:45:28 Topic: Assignments 16:45:44 Kathy: still techniques and failures that need to be assigned 16:46:02 Kathy: we don't need everything done but I'd like to have some examples so when the working group is looking at this they have a technique to see where were going with this 16:46:29 Kathy: David, you have 2.5.3 techniques – single tap long presses revocable 16:47:15 Kathy: Marc technique under 2.5.1 16:47:44 Kathy: look for headings, issues with numbering 16:48:23 Detlev: was meant to be assigned one about user knows position with an application but can't find it in technique development assignments 16:48:50 Kathy: most recent ones are not in technique development assignments, don't have numbers for them 16:49:14 Kathy: these are just in meeting agendas for now 16:49:22 Kathy: the one specifically for touch and pointer 16:49:50 Kathy: if you wanted to do another one or you had time you could modify – there are two already partially written to reflect the change that we did to pixels rather than 16:50:33 Kathy: any of the ones that are in the touch proposal that you like to do you can pick up, I'll try to get this in the wiki as well 16:51:03 Detlev we could review M016 and M27 which I have drafted 16:51:08 Kathy: will update techniques assignments and wiki and send to list 16:51:31 Topic: 2.5.5 touch clearance 16:51:58 Kathy: so for touch target clearance I think the change we need to do here is simply change 9 mm to 48 pixels 16:52:05 2.5.5 Touch Target Clearance: The center of each touch target has a distance of at least 9 mm from the center of any other touch target, except when the user has reduced the default scale of content. (Level AA) 16:52:19 Kathy: this is what we currently have 16:52:26 2.5.5 Touch Target Clearance: The center of each touch target has a distance of at least 48px from the center of any other touch target, except when the user has reduced the default scale of content. (Level AA) 16:53:05 2.5.5 Touch Target Clearance: The center of each touch target has a distance of at least 48px from the center of any other touch target. (Level AA) 16:53:31 Detlev: does it still make sense to have another technique that they shouldn't overlap 16:54:01 Kathy: if the touch targets overlap with that be a failure or technique 16:54:29 Kathy: you see it sometimes an responsive design 16:54:57 Detlev: is it mobile specific – you could have the same problem on the desktop, don't know which interactive element is on top of each other, same issue 16:55:24 Kathy: 48 pixels by 48 pixels – if 50 pixels and one pixel overlap, is that an issue? 16:56:33 Kathy: right now were saying touch target clearance needs to be 48 pixels by 48 pixels. The center from one element to another active element needs to be 48 pixels from the center to the center. But if we have elements that are 50 pixels each than we overlap by one pixel on either side. Is that an issue? They essentially meet the success criteria – touch target clearance has a distance of 48... 16:56:34 ...pixels, but if it's greater than that it's overlapping 16:57:00 Detlev: that's not such an issue if your finger is in the middle of the button you should be able to detect which one 16:57:45 Detlev: menu – flow into one another, do you want clearance between them 16:58:11 Kathy: BBC one pixel between? Why are we saying from the center of one touch target to the center of the other? 16:58:46 Detlev: even if your finger is just marginally inside 16:59:07 That was Alisair speaking... 16:59:27 Alistair: you could get rid of that one 17:00:08 Alistair: as Detlev pointed out that something that we may need to raise at a general level in WCAG – issue with overlapping buttons 17:01:10 David: overlapping buttons not siteing problem, but seeing problem 17:01:48 David: seems like we are starting to overlap into usability – worse for accessibility? 17:02:56 Alistair: probably the 48 pixels to the center of each one is probably redundant, could be removed 17:03:17 Alistair: we would have to think of one that was overlapping instead 17:03:38 Alistair: 48 pixels means they're large enough, maybe 48 x 48 visible pixels, that would solve the problem all around 17:04:12 Detlev: if the menu had enough space on a button wouldn't matter if there are 48 vertically, if there are 48 horizontally 17:04:24 David: better center to center because we don't want to prescribe how big the button is 17:05:28 Alistair: has to be visible on the screen. The other problem is you have a button 48 x 48 on top of another button 17:05:42 David: I'm wondering if her going to get pushback on 48 horizontal 17:07:05 Alistair: will modify and send email this week – using the 48 pixel language 17:09:45 zakim, list participants 17:09:45 As of this point the attendees have been jeanne, Kim, agarrison, alistair 17:10:24 present+ David, Detlev 17:10:33 zakim, list participants 17:10:33 As of this point the attendees have been jeanne, Kim, agarrison, alistair, David, Detlev 17:11:10 present+ Kathy 17:11:15 zakim, list participants 17:11:15 As of this point the attendees have been jeanne, Kim, agarrison, alistair, David, Detlev, Kathy 17:11:43 rrsagent, make minutes 17:11:43 I have made the request to generate http://www.w3.org/2016/01/21-mobile-a11y-minutes.html Kim 17:28:51 rrsagent, bye 17:28:51 I see no action items