14:51:12 RRSAgent has joined #mobile-a11y 14:51:12 logging to http://www.w3.org/2015/05/28-mobile-a11y-irc 14:51:14 RRSAgent, make logs public 14:51:14 Zakim has joined #mobile-a11y 14:51:16 Zakim, this will be WAI_MATF 14:51:16 ok, trackbot; I see WAI_MATF()11:00AM scheduled to start in 9 minutes 14:51:17 Meeting: Mobile Accessibility Task Force Teleconference 14:51:17 Date: 28 May 2015 14:51:26 chair: Kimberly_Patch 14:54:25 agenda+ Best Practices - Understandable 14:54:26 agenda+ Best Practices - Robust 14:54:28 agenda+ Next steps – next meeting Thursday, June 4 15:00:26 marcjohlic has joined #mobile-a11y 15:00:54 jeanne has joined #mobile-a11y 15:07:05 Detlev has joined #mobile-a11y 15:07:33 present+ jeanne 15:07:41 present+ 15:07:44 present+ marcjohlic 15:07:47 regrets+ Kathy 15:08:26 present+ MikeShebanek 15:08:35 present+ Detlev 15:09:55 zakim, pick a victim 15:09:55 sorry, jeanne, I don't know what conference this is 15:10:05 zakim, this is MATF 15:10:05 jeanne, I see WAI_MATF()11:00AM in the schedule but not yet started. Perhaps you mean "this will be MATF". 15:10:18 zakim, this will be MATF 15:10:18 ok, jeanne; I see WAI_MATF()11:00AM scheduled to start 10 minutes ago 15:10:26 zakim, pick a victim 15:10:26 sorry, jeanne, I don't know what conference this is 15:11:46 scribe: jeanne 15:11:53 zakim, take up item 1 15:11:53 agendum 1. "Best Practices - Understandable" taken up [from Kim] 15:13:54 Regrets+ Jan 15:14:44 https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Understandable_Techniques 15:15:26 regrets+ Michael_Pluke 15:16:07 http://w3c.github.io/Mobile-A11y-TF-Note/ 15:16:09 jon_avila has joined #mobile-a11y 15:17:10 Response from Lisa Seeman This is an early draft of some of what you are talking about: https://w3c.github.io/coga/issue-papers/links-buttons.html (We already have some changes to it, but I have not uploaded them yet.) 15:17:42 Topic: 3.6 Provide instructions for custom touchscreen and device manipulation gestures 15:18:15 Detlev: There are hints in iOS, that allows you to supplement instructions - at least to labels. 15:18:22 ... it may be iOS only 15:19:16 Marc: It is iOS specific - we have been adding info the label of the element, so that it will work on both platforms. It adds to the text being read. 15:19:37 Jon: The hint is misunderstood. It is supposed to be the result of the action. 15:20:22 ... adjustable controls will automatically give directions from iOS Voiceover 15:20:54 Mike: I think that the hint should be more than the result, it should tell the user how to perform the action. 15:21:17 https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html#//apple_ref/doc/uid/TP40008785-CH102-SW6 15:21:36 Jon: That is contrary to Apple documentation -- perhaps we should write a Technique to describe the best practice 15:22:01 Mike: We should go back to Apple to ask them to change that documentation. I believe it is native. 15:22:20 Jon: We are talking about custom instructions. 15:24:37 Jeanne: Lisa's note is interesting. I think we need to say that user agents must give instructions for actions that it understands. The author is responsible for custom widgets/gestures 15:25:32 Mike: THe use case I see a lot is that often there is the ability to swipe an object from off screen to on screen. The problem is that there is not an icon to indicate that the material is available. 15:26:16 Jon: It fits into the Help success criteria in WCAG, sometimes there are instructions when you launch an app to show the complex swipes. 15:27:29 Kim: Some apps have overlays that show you the gestures that can be used in the app. Then there is a button that shows how to turn it on and off. I have seen camera apps that use complex gestures 15:28:04 Mike: It is difficult to make accessible to a screenreader user -- to link the gesture with the instructions 15:28:35 Detlev: There are some examples of using ARIA for this with delayed text@@ 15:29:54 Jon: ARIA describedby can be used. The ARIA tooltip is difficult to get working when there is no hover, but describedby will always be spoken even if it is offscreen. 15:30:47 Kim: There are some apps that use different voices. It seems like a different layer of visual. 15:31:28 Jon: That is difficult to make work -- CSS doesn't work. The user would have to set up the different voices 15:32:31 Detlev: If there are hints, you could choose to not to render the hints. Like there is a technique to read short link text or longer link text. 15:32:56 Jon: This is a good technique that could be used in other web apps. 15:33:05 Jeanne: This seems like a user agent issue 15:33:45 Jon: JAWS has different verbosity settings. There is scripting to turn on and off JAWS hints. There is no programmatic way to communicate that to a webapp. 15:34:34 ... there was a Freedom Scientific proposal to add a help attribute to W3C, but it never went anywhere. 15:35:05 https://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0346.html 15:35:08 Technique for adding hints to iOS applications 15:35:43 Technique for turning hints on and off 15:36:25 ... these should also have a optional visual layer as well, as they are not only for audio. 15:37:59 This is also a good use case. Reminder that we have a use case wiki page, please add this to it. 15:39:28 Detlev: sometimes hints should be different depending on whether or not you are using a screenreader, which could lead to forking. It's probably not doable. 15:40:29 Kim: Why can't the user specify that they want hints for screenreader or switch use 15:41:03 Detlev: I don't think it is doable, because it requires the author to write different types of hints. 15:41:22 Detlev: It is hypothetical at the moment. 15:41:45 Kim: It's good for testing. 15:42:22 Jeanne: There are serious privacy issues for using sniffers. 15:42:55 Jon: you could use tell what the user is doing by looking to see whether they are using keyboard events. 15:43:18 http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Accessibility_Use_Cases 15:43:41 ... if we put it in terms of behaviours instead of disabilities, that is more helpful to the user and helps with the privacy issues. 15:44:51 Jeanne: I would like to see a visual indicator that there is information off screen. 15:45:09 Kim: iOS has elegent dots and a number of how many screens. 15:45:48 Mike: SOme designers will reveal a corner or sliver of something off screen to give people an idea there is more material available to swipe. 15:46:42 Detlev: an animation affordance hint that indicates there is more material. I am not sure we want to recommend it because it is visual only, and not available to other modes. 15:46:52 Kim: or if you aren't paying attention 15:47:03 Detlev: I don't think we want to ban it 15:47:48 Jeanne: it could be an example in a technique - as long as it is available in other modalities 15:48:19 Jon: another one is the labels that shake when an error is made -- the shake doesn't give you any information about the error. 15:48:46 Kim: It seems like there are two techniques here -- information vs information available. 15:49:39 Jon: the shaking could be put under existing SC, make them new failure conditions 15:50:22 ... could we use 1.3.3 Sensory Characteristics for instructions such as shake or other failures 15:50:37 ... we have Predictable, but we don't have affordances or discoverable 15:51:32 Detlev: a small tab on the left, if you have no way of focusing with the screenreader, you would have to make it focusable. It would be an elegent solution that would be available to other modalities. 15:51:49 Kim: We should indicate 1.3.3 here 15:52:26 JOn: 2.1.1 keyboard -- if there is a visual indicator, then it has to be focusable. 15:52:48 Dtlev: and the swipe must be keyboard accessible, but we have already discussed this. 15:53:05 Kim: What about Form Datatypes? 15:53:41 Detlev: Don't use placeholder text alone, with no label. 15:53:54 ... is there a current WCAG technique on Placeholder Text 15:54:09 Jon: Not in current WCAG, but it is in HTML 15:55:03 Detlev: Placeholder text will be read when you enter the field, but if anything is entered, then the placeholder text will not be read after that, unless it is marked up with ARIA label. I don't know how to do that with native apps. 15:55:44 Jon: There are ways to do it like, labelfor. Talkback announces it after the field rather than before the field. It will remain even after something is typed. 15:56:59 Kim: there are a lot of programs that have a Back button even in the app. If they can go back and see that placeholder text. THere are a lot of good reasons to go back, for speech users who accidently trip an unexpected command. Lot undo, but for visual view. 15:57:49 ... that could sidestep placeholder text. 15:58:21 Technique for Placeholder text and correctly labeling it if it is used. 16:00:37 Detlev: Need a Technioque for ways of marking up groups of labels because Fieldset does not work on some mobile environments in iOS. It makes elements hard to use. 16:00:59 Jeanne: I think this is a bug to file against iOS. 16:01:31 Jon: Already done. But there is also an aria technique to handle this. 16:03:35 Kim_ has joined #mobile-a11y 16:08:08 rrsagent, make minutes 16:08:08 I have made the request to generate http://www.w3.org/2015/05/28-mobile-a11y-minutes.html jeanne 16:08:53 rrsagent, make logs public 16:09:08 present+ kim 16:09:26 present+ JonAvila 16:09:40 rrsagent, make minutes 16:09:40 I have made the request to generate http://www.w3.org/2015/05/28-mobile-a11y-minutes.html jeanne 16:59:27 topic #ua WebEx https://mit.webex.com/mit/e.php?MTID=mbd0f7b747d2bc4897eeb4536b84bdba5