14:54:55 RRSAgent has joined #mobile-a11y 14:54:55 logging to http://www.w3.org/2016/05/05-mobile-a11y-irc 14:54:57 RRSAgent, make logs public 14:54:57 Zakim has joined #mobile-a11y 14:54:59 Zakim, this will be WAI_MATF 14:54:59 ok, trackbot 14:55:00 Meeting: Mobile Accessibility Task Force Teleconference 14:55:00 Date: 05 May 2016 14:55:19 chriscm has joined #mobile-a11y 14:56:09 Agenda+ Status Mobile Touch & Pointer guideline and success criteria 14:56:10 Agenda+ Review of next steps – mobile guidelines: 2.6, 2.7, 3.4, 3.5 14:57:08 I see so many connected to chat already, but nobody on the WebEx. Am I in the right meeting? :) 14:57:36 yes -- b right there 14:59:08 Kathy has joined #mobile-a11y 15:02:03 present+ patrick_h_lauke 15:02:11 (sorry running a minute late, just dialing in) 15:04:34 jon_avila has joined #mobile-a11y 15:04:39 present+jon_avila 15:04:51 present+ Kathy 15:05:02 present+ Kim 15:05:23 marcjohlic has joined #mobile-a11y 15:06:12 regrets+ Henny, Alistair, Alan 15:06:26 zakim, take up next 15:06:26 agendum 1. "Status Mobile Touch & Pointer guideline and success criteria" taken up [from Kim] 15:07:35 Kathy: Jeanne separated out touch and pointer, working on survey that will ask people to put comments in github. Three weeks, feedback until end of May, then we will take up comments 15:08:54 q+ to ask to forward the meeting agenda with connection info. 15:08:56 davidmacdonald has joined #mobile-a11y 15:09:00 present+ marcjohlic 15:09:02 Kathy: also just had a call with the other task force coordinators and working group chairs – direction moving forward. Meeting on Tuesday working group call. Because all of you are not only part of the task force but are part of the WCAG working group you can attend that meeting. About structure going forward. I highly encourage you to attend this call on Tuesday. They've collected a lot of... 15:09:04 ...different models and they've gone through the pros and cons of all of those and they are going to present that on Tuesday. Call is at 11 o'clock Eastern standard Time 15:09:11 Kathy: you can also watch the mailing list for minutes of that meeting 15:09:30 Kathy: will forward the email for that meeting 15:10:00 q- 15:10:07 Kathy: appropriate discussion links will also be in the survey 15:10:27 zakim, take up next 15:10:27 agendum 2. "Review of next steps – mobile guidelines: 2.6, 2.7, 3.4, 3.5" taken up [from Kim] 15:10:35 Kathy: two goals going forward 15:11:02 Kathy: get this finalized within a year – have a good foundation but techniques etc. Also coordinate with the other taskforces 15:11:26 Kathy: today review the guidelines outlined from our original notes 15:12:11 Kathy: talk about as a group where we want to focus next. Also, with a list of items we want to coordinate with either the low vision or the cognitive task force – for example looking at color contrast on mobile with low vision - talk about together 15:12:29 Kathy: next week after the call with WCAG we will talk more about getting a timeline together 15:12:36 Kathy: any questions 15:12:39 q? 15:13:57 Kathy: let's start by talking through the different items. We've been talking for the last month of pout touch and pointer, which is out for review now. Other guidelines: 2.6physical features of the phone, 2.7speech input users, 3.4content usable in different orientations, 3.5interactive elements distinguishable 15:14:34 +1 Kim for working on those that need coordination. 15:14:42 I don't have a preference 15:15:10 I think it is better to work on coordinating before either one of us is fixed into a position and have to re-do work. 15:15:55 Patrick: everything not strictly mobile? 15:16:34 Kathy: yes all of this is things that could be applicable across groups, and the way we have it everything is going to be incorporated together – we may have a quick reference that allows you to see things specifically for mobile but not specifically a mobile extension – it will be incorporated. Which is why the coordination is important 15:17:04 q+ 15:17:06 Patrick: speech input is there a group that's more suitable are do we throw the doors open to an entire working group or is the understanding we'll do a first pass 15:17:21 Patrick: maybe we haven't had the direct expertise on that 15:18:25 Kathy: Kim has the expertise and I'm also a Dragon user – there is expertise in this group and I'd like to see it go in otherwise it's going to get lost. Kim's done work in that already that we can propose to the wider group for feedback. It's not necessarily something were going to focus a lot of time on but it is important. Also speech is important for mobile but not just applicable for... 15:18:26 reassured to hear that we do have expertise in this area already in the group 15:18:26 ...mobile 15:19:38 is it just speech input, or also speech output? (just asking as i heard mention of "when they get a text message, they hit the speech button") 15:19:41 David: echoing that there's a gap with speech, and people are using speech on mobile more than anything else now. Siri and the speech button. It does need to get done. We have some difficulties on mobile because you can't do everything with a keyboard. 15:20:51 David: keyboard work in mobile browser is there a mobile browser that you can do full keyboard 15:21:08 Patrick: not iOS – without voiceover can't navigate everything 15:21:23 David: there are some things – home screen 15:22:18 Chris: you can do quite a bit with the keyboard. It certainly works better with voiceover active but both android and iOS have this separated concept of keyboard focus versus accessibility focus. IOS tends to link them more with AT on. Android actually better without AT. But both roughly accessible with and without 15:22:24 Chris: but it's not intuitive 15:22:50 David: Space is enter key. 15:23:01 Chris: arrow keys more than tab 15:23:26 David: overall is good enough, but a little bit of concern2.7 how are we going to address this knowing that you can't do everything with keyboard in iOS. That's one of the questions to solve 15:23:50 http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/ 15:24:20 http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/ 15:24:54 ACTION: Chris blog item on keyboard shortcuts on iOS and Android and send us the link 15:24:54 Created ACTION-51 - Blog item on keyboard shortcuts on ios and android and send us the link [on Chris McMeeking - due 2016-05-12]. 15:25:41 I agree with Patrick 15:26:32 Patrick: from a browser point of view you can do very little. If it doesn't work on Safari it won't work on others because they are just safari under the hood – that's the general situation for Web content under iOS. Don't think you can send JavaScript key commands already. So a lot of the aria that have been explicitly written to – user can just use arrow keys and add event handlers for... 15:26:34 ...keyboard like key down or keypress they will not be triggered – keyword doesn't send any through the browser – browser never receives any key events 15:26:51 Bottom of this page has 4 levels of VoiceOver keyboard commands: "VoiceOver Command Charts" http://www.apple.com/accessibility/resources/ 15:26:59 Chris: so you have to turn on voiceover. 15:27:18 Patrick: something needs to be focusable and actionable 15:28:17 David: I don't see a reason why iOS can't fill in the gaps. I think we can be a bit ahead of the curve and push this 15:28:25 This may also be helpful: http://www.interactiveaccessibility.com/education/training/downloads/Testing-BluetoothKeyboard-iOS.pdf 15:28:45 My ARIA page lists issues related to keyboard access in addition to other ARIA information http://mraccess77.github.io/test_results/ARIA_Mobile_Browser_Support.html 15:28:48 David: I think we can push ahead with 2.7.2 and not hold it back 15:29:19 Kathy: which one do we do next? 2.5 collaboration with cognitive? 15:29:26 sounds good 15:29:37 David: we overlap with both cognitive and low vision on this one 15:30:45 Kathy: we could pick up this one, create some success criteria, then have discussion with low vision and cognitive and incorporate that in – that's one approach. The other approach is to take one that's not specific to any of the others, for example 2.4, which is more geared toward mobile specifically 15:31:40 David: I would say we would want to work where we can find success criterion. 2.5.3, Clearly distinguishable is not measurable 15:32:04 Kathy: all of these we want to work on. My thought is either guideline 3.5 or to continue on and talk about 2.7 because it goes along with a touch and pointer as different ways to interact 15:32:12 google doc where we documented some of the areas where ARIA patterns fall apart on touch devices and in mobile+keyboard scenarios https://docs.google.com/spreadsheets/d/1gN9oRZPdrJxLDNtT6nVO4fn7E7sn1061L9Xl3__slZ4/edit#gid=0 15:32:15 David: low hanging fruit right now 15:32:33 David: 2.4.1 looks like pretty low hanging fruit, changes in orientation 15:32:38 referenced from http://w3c.github.io/aria-in-html/#aria-touch 15:32:49 David: Chris, how would I programmatically orientation 15:33:27 https://www.w3.org/TR/orientation-event/ 15:33:35 David: the problem I think that were trying to solve here is a guy is in a wheelchair, landscape you, can't switch. AT that he might be using, in this case scanning would be able to know and change orientation 15:33:58 Jeanne: can set fixed orientation in a webpage 15:34:11 q+ 15:34:17 Chris: can set orientation in devices themselves – that's a device problem 15:35:04 Jeanne: this was for Web browsers that have set page 15:35:16 Chris: 15:35:35 Chris: Webpage doesn't know device setting 15:35:35 https://drafts.csswg.org/css-device-adapt/#orientation-desc 15:36:37 https://www.w3.org/TR/orientation-event/ 15:36:48 https://www.w3.org/TR/screen-orientation/ 15:36:53 Chris: portrait versus landscape – on a tablet and you are oriented in a kind of portrait mode things are going to lineup up and down instead of side to side. For phone users that's not really an issue. Screen is still small enough that pixel density is small enough that you're still gonna have that mobile looking layout. But on tablets enough screen real estate that it switches to the... 15:36:54 ...desktop layout – the problem is the differences in layouts that you get when switching, especially on tablets 15:37:12 Some mobile applications automatically set the screen to a particular display orientation (landscape or portrait) and expect that users will respond by rotating the mobile device to match. However, some users have their mobile devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair). 15:37:14 Therefore, mobile application developers should try to support both orientations. If it is not possible to support both orientations, developers should ensure that it is easy for all users to change the orientation to return to a point at which their device orientation is supported. 15:37:15 Changes in orientation must be programmatically exposed to ensure detection by assistive technology such as screen readers. For example, if a screen reader user is unaware that the orientation has changed the user might perform incorrect navigation commands. 15:37:17 You can detect orientation but you can't change it from JavaScript 15:37:51 Correct 15:37:59 Chris: for native applications it's completely different – you can lock in and that's really bad for someone who can't change orientation – for native apps this is a huge issue 15:38:22 Jeanne: dropped in orientation specs 15:38:32 https://drafts.csswg.org/css-device-adapt/#orientation-desc 15:39:30 Patrick: authors do in a haphazard way currently because they can detect the orientation – many games for mobile which are only designed to work in landscape and if you view that particular page in portrait all you get is please turn your device to landscape mode. So some, however valid or not, already do this. So I'm assuming for mobile this area can be problematic 15:40:38 q- 15:40:39 Patrick: I think in general there's a lot of crossover – falls along the lines of the more responsive approach in general of making sure that you are not blocking users based on the aspect ratio of their viewpoint. Don't block your content to only work in specific aspect ratios 15:40:51 Some Android Keystrokes http://freaktab.com/forum/tv-player-support/general-tv-player-dicussions/19428-android-external-keyboard-shortcut-keys-documentation 15:40:52 q- 15:41:33 Chris: is that an accessibility issue or user issue. Looking at screen and saying is my X real estate greater than my Y real estate – issue for everyone. Is there a use case that calls for X to be greater than the Y. 15:42:11 Patrick: might be a softer AAA, but there are groups it would affect more than others 15:42:33 Kathy: just needs to be usable at a specific orientation – might be the ideal 15:42:44 Chris: with the real issue be just not allowing the orientation to change 15:42:49 Kathy: yes 15:43:26 Kathy: it's not that you're locking into a specific orientation, just that you're not allowing them to change. if it's not locked, you can use it in portrait size on the landscape screen 15:44:07 David: a mechanism is available to change the orientation… If they've overridden the mechanisms that will fail. 15:44:17 David: if we just keep people from locking it we may have a pretty easy success criterion to get through here 15:45:17 q+ 15:45:34 Patrick: instead of making it about the mechanism making it about the content – content can be experienced at different orientations. The idea of a mechanism to switch it is sufficient technique, possibly exceptions for things like if the content actually requires – is only one aspect ratio providing that is a, similar to playing piano on the screen 15:46:26 What if you need the landscape area to display content? 15:47:08 David: we had quite a few discussions during WCAG 2 about that. Passive to say can change the orientation, the more active a mechanism is available. I think they say the same thing. A mechanism is available is saying it could be anywhere, just somehow this can be done. And then you can have a failure technique to change orientation or something like that 15:48:13 to me "mechanism" just makes me think of "authors need to provide a switch", when in most cases it's about "don't lock it / don't do something" 15:48:45 Chris: I don't know what precedent is here but the reason I don't like a mechanism is available is because screen orientation and setting are heavily linked to the way the operating system wants to do things – what it tells native apps, web browsers to render. So the reason I don't like a mechanism is available to change the orientation is because what if you are a user who has enabled that... 15:48:47 ...locking of the orientation and so you are sitting there using it in portrait mode and then what I'm envisioning if you use a mechanism is available what you would allow to happen is for someone to come into an application and have it initially be sideways. So they see this perhaps I'd ways perhaps upside down version of the orientation and then there's a toggle in the corner that the user... 15:48:48 ...is reading upside down that says rotate 90°. That wording allows that to happen. That's why I don't like it. I think you should say don't override the OS or user agent perception of what up and down is 15:49:01 Patrick: that sounds to me like a sufficient technique 15:49:26 Patrick: it would satisfy the success criterion 15:49:33 Chris: but is it useful to the user if it's upside down 15:50:11 Patrick: when I read a mechanism is available that immediately makes me think I have to do something, where in effect it's the opposite. I shouldn't block orientation I shouldn't force a orientation, so it's something less that I should do rather than having something 15:50:18 Chris: don't fight it working the way it wants to work 15:50:23 1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A) 15:50:25 Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference. 15:50:47 David: example – when they use this mechanism they always have a note containing more information 15:51:57 David: fallback is the author has to do something or the browser does it. Came about with zoom. Some of the browsers could do it then and some of them couldn't. Gives a guilt feeling on the author to do something, but if it's not in the browser or the operating systems are going to have to do it 15:52:56 Patrick: looking at some of the other SCs wordings. 1.4.1 use of color – actively says 15:53:43 Natural orientationdoes not override the orientation OR a mechanism is available 15:53:49 Patrick: subject is content rather than immediately jumping to the opposite side with mechanism wording – seems like a double negative to get to the result 15:54:35 David: how about starting out with don't override 15:54:40 Patrick: cautiously yes 15:55:09 David: I think this could be a next candidate.It seems like we are moving in a direction. Chris has a really great thing to think about – the instruction is upside down 15:55:52 David: I don't see another way out right now. You don't want to handcuff the author so much that he can't make his game. Is there a way to suss out the mechanism that's being used on the device and provide notification to that mechanism in a way that is not broken and use current orientation 15:56:16 Chris: there are for native apps but the only way to do it for apps on websites are Hackey 15:56:35 Patrick: iOS and most recent android supported – have to research it 15:56:53 Kathy: I think it's worthwhile to do research on that. Maybe a page on the wiki and start that research 15:57:13 deviceorientation supported in all current mobile platforms http://caniuse.com/#search=deviceorientation 15:57:13 Content does not override the user's device orientation OR a mechanism is available to change the orientation. 15:57:21 Kathy: two different success criteria under that guideline. It doesn't really cross over to the other taskforces right now 15:58:53 Kathy: if we can all start thinking about this will have a more detailed discussion and will continue work. I'll send you the details about that call on Tuesday 16:01:36 while i'm here, can i shamelessly ask if anybody has any comments on this? https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0425.html (just because it circles the same drain we went around of "physical measures vs pixels") :) 16:01:37 rrsagent, make minutes 16:01:37 I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim 16:02:30 zakim, list participants 16:02:30 As of this point the attendees have been patrick_h_lauke, jon_avila, Kathy, Kim, marcjohlic 16:03:12 Present+ Jeanne, David 16:03:23 rrsagent, make minutes 16:03:23 I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim 16:03:58 Present+ Chris 16:04:06 rrsagent, make minutes 16:04:06 I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim 16:04:50 chair: Kathleen_Wahlbin 16:04:59 chair: Kathleen_Wahlbin 16:05:13 rrsagent, make minutes 16:05:13 I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim 16:33:26 rrsagent, bye 16:33:26 I see 1 open action item saved in http://www.w3.org/2016/05/05-mobile-a11y-actions.rdf : 16:33:26 ACTION: Chris blog item on keyboard shortcuts on iOS and Android and send us the link [1] 16:33:26 recorded in http://www.w3.org/2016/05/05-mobile-a11y-irc#T15-24-54