IRC log of mobile-a11y on 2016-05-05

Timestamps are in UTC.

14:54:55 [RRSAgent]
RRSAgent has joined #mobile-a11y
14:54:55 [RRSAgent]
logging to http://www.w3.org/2016/05/05-mobile-a11y-irc
14:54:57 [trackbot]
RRSAgent, make logs public
14:54:57 [Zakim]
Zakim has joined #mobile-a11y
14:54:59 [trackbot]
Zakim, this will be WAI_MATF
14:54:59 [Zakim]
ok, trackbot
14:55:00 [trackbot]
Meeting: Mobile Accessibility Task Force Teleconference
14:55:00 [trackbot]
Date: 05 May 2016
14:55:19 [chriscm]
chriscm has joined #mobile-a11y
14:56:09 [Kim]
Agenda+ Status Mobile Touch & Pointer guideline and success criteria
14:56:10 [Kim]
Agenda+ Review of next steps – mobile guidelines: 2.6, 2.7, 3.4, 3.5
14:57:08 [chriscm]
I see so many connected to chat already, but nobody on the WebEx. Am I in the right meeting? :)
14:57:36 [Kim]
yes -- b right there
14:59:08 [Kathy]
Kathy has joined #mobile-a11y
15:02:03 [patrick_h_lauke]
present+ patrick_h_lauke
15:02:11 [patrick_h_lauke]
(sorry running a minute late, just dialing in)
15:04:34 [jon_avila]
jon_avila has joined #mobile-a11y
15:04:39 [jon_avila]
present+jon_avila
15:04:51 [Kathy]
present+ Kathy
15:05:02 [Kim]
present+ Kim
15:05:23 [marcjohlic]
marcjohlic has joined #mobile-a11y
15:06:12 [Kim]
regrets+ Henny, Alistair, Alan
15:06:26 [Kim]
zakim, take up next
15:06:26 [Zakim]
agendum 1. "Status Mobile Touch & Pointer guideline and success criteria" taken up [from Kim]
15:07:35 [Kim]
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 [jeanne]
q+ to ask to forward the meeting agenda with connection info.
15:08:56 [davidmacdonald]
davidmacdonald has joined #mobile-a11y
15:09:00 [marcjohlic]
present+ marcjohlic
15:09:02 [Kim]
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 [Kim]
...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 [Kim]
Kathy: you can also watch the mailing list for minutes of that meeting
15:09:30 [Kim]
Kathy: will forward the email for that meeting
15:10:00 [jeanne]
q-
15:10:07 [Kim]
Kathy: appropriate discussion links will also be in the survey
15:10:27 [Kim]
zakim, take up next
15:10:27 [Zakim]
agendum 2. "Review of next steps – mobile guidelines: 2.6, 2.7, 3.4, 3.5" taken up [from Kim]
15:10:35 [Kim]
Kathy: two goals going forward
15:11:02 [Kim]
Kathy: get this finalized within a year – have a good foundation but techniques etc. Also coordinate with the other taskforces
15:11:26 [Kim]
Kathy: today review the guidelines outlined from our original notes
15:12:11 [Kim]
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 [Kim]
Kathy: next week after the call with WCAG we will talk more about getting a timeline together
15:12:36 [Kim]
Kathy: any questions
15:12:39 [Kathy]
q?
15:13:57 [Kim]
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 [jeanne]
+1 Kim for working on those that need coordination.
15:14:42 [jon_avila]
I don't have a preference
15:15:10 [jeanne]
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 [Kim]
Patrick: everything not strictly mobile?
15:16:34 [Kim]
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 [davidmacdonald]
q+
15:17:06 [Kim]
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 [Kim]
Patrick: maybe we haven't had the direct expertise on that
15:18:25 [Kim]
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 [patrick_h_lauke]
reassured to hear that we do have expertise in this area already in the group
15:18:26 [Kim]
...mobile
15:19:38 [patrick_h_lauke]
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 [Kim]
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 [Kim]
David: keyboard work in mobile browser is there a mobile browser that you can do full keyboard
15:21:08 [Kim]
Patrick: not iOS – without voiceover can't navigate everything
15:21:23 [Kim]
David: there are some things – home screen
15:22:18 [Kim]
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 [Kim]
Chris: but it's not intuitive
15:22:50 [Kim]
David: Space is enter key.
15:23:01 [Kim]
Chris: arrow keys more than tab
15:23:26 [Kim]
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 [patrick_h_lauke]
http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/
15:24:20 [davidmacdonald]
http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/
15:24:54 [Kim]
ACTION: Chris blog item on keyboard shortcuts on iOS and Android and send us the link
15:24:54 [trackbot]
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 [jon_avila]
I agree with Patrick
15:26:32 [Kim]
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 [Kim]
...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 [marcjohlic]
Bottom of this page has 4 levels of VoiceOver keyboard commands: "VoiceOver Command Charts" http://www.apple.com/accessibility/resources/
15:26:59 [Kim]
Chris: so you have to turn on voiceover.
15:27:18 [Kim]
Patrick: something needs to be focusable and actionable
15:28:17 [Kim]
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 [marcjohlic]
This may also be helpful: http://www.interactiveaccessibility.com/education/training/downloads/Testing-BluetoothKeyboard-iOS.pdf
15:28:45 [jon_avila]
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 [Kim]
David: I think we can push ahead with 2.7.2 and not hold it back
15:29:19 [Kim]
Kathy: which one do we do next? 2.5 collaboration with cognitive?
15:29:26 [jon_avila]
sounds good
15:29:37 [Kim]
David: we overlap with both cognitive and low vision on this one
15:30:45 [Kim]
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 [Kim]
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 [Kim]
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 [patrick_h_lauke]
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 [Kim]
David: low hanging fruit right now
15:32:33 [Kim]
David: 2.4.1 looks like pretty low hanging fruit, changes in orientation
15:32:38 [patrick_h_lauke]
referenced from http://w3c.github.io/aria-in-html/#aria-touch
15:32:49 [Kim]
David: Chris, how would I programmatically orientation
15:33:27 [patrick_h_lauke]
https://www.w3.org/TR/orientation-event/
15:33:35 [Kim]
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 [Kim]
Jeanne: can set fixed orientation in a webpage
15:34:11 [patrick_h_lauke]
q+
15:34:17 [Kim]
Chris: can set orientation in devices themselves – that's a device problem
15:35:04 [Kim]
Jeanne: this was for Web browsers that have set page
15:35:16 [Kim]
Chris:
15:35:35 [Kim]
Chris: Webpage doesn't know device setting
15:35:35 [patrick_h_lauke]
https://drafts.csswg.org/css-device-adapt/#orientation-desc
15:36:37 [jeanne]
https://www.w3.org/TR/orientation-event/
15:36:48 [jeanne]
https://www.w3.org/TR/screen-orientation/
15:36:53 [Kim]
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 [Kim]
...desktop layout – the problem is the differences in layouts that you get when switching, especially on tablets
15:37:12 [davidmacdonald]
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 [davidmacdonald]
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 [davidmacdonald]
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 [jon_avila]
You can detect orientation but you can't change it from JavaScript
15:37:51 [jon_avila]
Correct
15:37:59 [Kim]
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 [Kim]
Jeanne: dropped in orientation specs
15:38:32 [patrick_h_lauke]
https://drafts.csswg.org/css-device-adapt/#orientation-desc
15:39:30 [Kim]
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 [patrick_h_lauke]
q-
15:40:39 [Kim]
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 [jon_avila]
Some Android Keystrokes http://freaktab.com/forum/tv-player-support/general-tv-player-dicussions/19428-android-external-keyboard-shortcut-keys-documentation
15:40:52 [davidmacdonald]
q-
15:41:33 [Kim]
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 [Kim]
Patrick: might be a softer AAA, but there are groups it would affect more than others
15:42:33 [Kim]
Kathy: just needs to be usable at a specific orientation – might be the ideal
15:42:44 [Kim]
Chris: with the real issue be just not allowing the orientation to change
15:42:49 [Kim]
Kathy: yes
15:43:26 [Kim]
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 [Kim]
David: a mechanism is available to change the orientation… If they've overridden the mechanisms that will fail.
15:44:17 [Kim]
David: if we just keep people from locking it we may have a pretty easy success criterion to get through here
15:45:17 [chriscm]
q+
15:45:34 [Kim]
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 [jon_avila]
What if you need the landscape area to display content?
15:47:08 [Kim]
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 [patrick_h_lauke]
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 [Kim]
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 [Kim]
...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 [Kim]
...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 [Kim]
Patrick: that sounds to me like a sufficient technique
15:49:26 [Kim]
Patrick: it would satisfy the success criterion
15:49:33 [Kim]
Chris: but is it useful to the user if it's upside down
15:50:11 [Kim]
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 [Kim]
Chris: don't fight it working the way it wants to work
15:50:23 [davidmacdonald]
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 [davidmacdonald]
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 [Kim]
David: example – when they use this mechanism they always have a note containing more information
15:51:57 [Kim]
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 [Kim]
Patrick: looking at some of the other SCs wordings. 1.4.1 use of color – actively says
15:53:43 [davidmacdonald]
Natural orientationdoes not override the orientation OR a mechanism is available
15:53:49 [Kim]
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 [Kim]
David: how about starting out with don't override
15:54:40 [Kim]
Patrick: cautiously yes
15:55:09 [Kim]
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 [Kim]
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 [Kim]
Chris: there are for native apps but the only way to do it for apps on websites are Hackey
15:56:35 [Kim]
Patrick: iOS and most recent android supported – have to research it
15:56:53 [Kim]
Kathy: I think it's worthwhile to do research on that. Maybe a page on the wiki and start that research
15:57:13 [patrick_h_lauke]
deviceorientation supported in all current mobile platforms http://caniuse.com/#search=deviceorientation
15:57:13 [davidmacdonald]
Content does not override the user's device orientation OR a mechanism is available to change the orientation.
15:57:21 [Kim]
Kathy: two different success criteria under that guideline. It doesn't really cross over to the other taskforces right now
15:58:53 [Kim]
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 [patrick_h_lauke]
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 [Kim]
rrsagent, make minutes
16:01:37 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim
16:02:30 [Kim]
zakim, list participants
16:02:30 [Zakim]
As of this point the attendees have been patrick_h_lauke, jon_avila, Kathy, Kim, marcjohlic
16:03:12 [Kim]
Present+ Jeanne, David
16:03:23 [Kim]
rrsagent, make minutes
16:03:23 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim
16:03:58 [Kim]
Present+ Chris
16:04:06 [Kim]
rrsagent, make minutes
16:04:06 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim
16:04:50 [Kim]
chair: Kathleen_Wahlbin
16:04:59 [Kim]
chair: Kathleen_Wahlbin
16:05:13 [Kim]
rrsagent, make minutes
16:05:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/05-mobile-a11y-minutes.html Kim
16:33:26 [Kim]
rrsagent, bye
16:33:26 [RRSAgent]
I see 1 open action item saved in http://www.w3.org/2016/05/05-mobile-a11y-actions.rdf :
16:33:26 [RRSAgent]
ACTION: Chris blog item on keyboard shortcuts on iOS and Android and send us the link [1]
16:33:26 [RRSAgent]
recorded in http://www.w3.org/2016/05/05-mobile-a11y-irc#T15-24-54