Mobile Accessibility Task Force Teleconference -- 05 May 2016

<chriscm> I see so many connected to chat already, but nobody on the WebEx. Am I in the right meeting? :)

yes -- b right there

<patrick_h_lauke> (sorry running a minute late, just dialing in)

Status Mobile Touch & Pointer guideline and success criteria

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
... 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...
... 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
... you can also watch the mailing list for minutes of that meeting
... will forward the email for that meeting
... appropriate discussion links will also be in the survey

Review of next steps – mobile guidelines: 2.6, 2.7, 3.4, 3.5

Kathy: two goals going forward
... get this finalized within a year – have a good foundation but techniques etc. Also coordinate with the other taskforces
... today review the guidelines outlined from our original notes
... 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
... next week after the call with WCAG we will talk more about getting a timeline together
... any questions
... 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

<jeanne> +1 Kim for working on those that need coordination.

<jon_avila> I don't have a preference

<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.

Patrick: everything not strictly mobile?

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

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
... maybe we haven't had the direct expertise on that

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...

<patrick_h_lauke> reassured to hear that we do have expertise in this area already in the group

Kathy: mobile

<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")

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.
... keyboard work in mobile browser is there a mobile browser that you can do full keyboard

Patrick: not iOS – without voiceover can't navigate everything

David: there are some things – home screen

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
... but it's not intuitive

David: Space is enter key.

Chris: arrow keys more than tab

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

<patrick_h_lauke> http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/

<davidmacdonald> http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/

<scribe> ACTION: Chris blog item on keyboard shortcuts on iOS and Android and send us the link [recorded in http://www.w3.org/2016/05/05-mobile-a11y-minutes.html#action01]

<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].

<jon_avila> I agree with Patrick

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...
... 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

<marcjohlic> Bottom of this page has 4 levels of VoiceOver keyboard commands: "VoiceOver Command Charts" http://www.apple.com/accessibility/resources/

Chris: so you have to turn on voiceover.

Patrick: something needs to be focusable and actionable

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

<marcjohlic> This may also be helpful: http://www.interactiveaccessibility.com/education/training/downloads/Testing-BluetoothKeyboard-iOS.pdf

<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

David: I think we can push ahead with 2.7.2 and not hold it back

Kathy: which one do we do next? 2.5 collaboration with cognitive?

<jon_avila> sounds good

David: we overlap with both cognitive and low vision on this one

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

David: I would say we would want to work where we can find success criterion. 2.5.3, Clearly distinguishable is not measurable

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

<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

David: low hanging fruit right now
... 2.4.1 looks like pretty low hanging fruit, changes in orientation

<patrick_h_lauke> referenced from http://w3c.github.io/aria-in-html/#aria-touch

David: Chris, how would I programmatically orientation

<patrick_h_lauke> https://www.w3.org/TR/orientation-event/

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

Jeanne: can set fixed orientation in a webpage

Chris: can set orientation in devices themselves – that's a device problem

Jeanne: this was for Web browsers that have set page

Chris: ... Webpage doesn't know device setting

<patrick_h_lauke> https://drafts.csswg.org/css-device-adapt/#orientation-desc

<jeanne> https://www.w3.org/TR/orientation-event/

<jeanne> https://www.w3.org/TR/screen-orientation/

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...
... desktop layout – the problem is the differences in layouts that you get when switching, especially on tablets

<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).

<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.

<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.

<jon_avila> You can detect orientation but you can't change it from JavaScript

<jon_avila> Correct

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

Jeanne: dropped in orientation specs

<patrick_h_lauke> https://drafts.csswg.org/css-device-adapt/#orientation-desc

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
... 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

<jon_avila> Some Android Keystrokes http://freaktab.com/forum/tv-player-support/general-tv-player-dicussions/19428-android-external-keyboard-shortcut-keys-documentation

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.

Patrick: might be a softer AAA, but there are groups it would affect more than others

Kathy: just needs to be usable at a specific orientation – might be the ideal

Chris: with the real issue be just not allowing the orientation to change

Kathy: yes
... 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

David: a mechanism is available to change the orientation… If they've overridden the mechanisms that will fail.
... if we just keep people from locking it we may have a pretty easy success criterion to get through here

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

<jon_avila> What if you need the landscape area to display content?

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

<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"

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...
... 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...
... 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

Patrick: that sounds to me like a sufficient technique
... it would satisfy the success criterion

Chris: but is it useful to the user if it's upside down

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

Chris: don't fight it working the way it wants to work

<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)

<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.

David: example – when they use this mechanism they always have a note containing more information
... 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

Patrick: looking at some of the other SCs wordings. 1.4.1 use of color – actively says

<davidmacdonald> Natural orientationdoes not override the orientation OR a mechanism is available

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

David: how about starting out with don't override

Patrick: cautiously yes

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
... 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

Chris: there are for native apps but the only way to do it for apps on websites are Hackey

Patrick: iOS and most recent android supported – have to research it

Kathy: I think it's worthwhile to do research on that. Maybe a page on the wiki and start that research

<patrick_h_lauke> deviceorientation supported in all current mobile platforms http://caniuse.com/#search=deviceorientation

<davidmacdonald> Content does not override the user's device orientation OR a mechanism is available to change the orientation.

Kathy: two different success criteria under that guideline. It doesn't really cross over to the other taskforces right now
... 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

<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") :)

<scribe> chair: Kathleen_Wahlbin

- DRAFT -

Mobile Accessibility Task Force Teleconference

05 May 2016

Attendees

Contents

Status Mobile Touch & Pointer guideline and success criteria

Review of next steps – mobile guidelines: 2.6, 2.7, 3.4, 3.5

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output