W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

12 Nov 2015

See also: IRC log

Attendees

Present
Kathy, Kim, jon_avila, Alistair, marcjohlic, 1, Jan, Detlev, David
Regrets
Chair
Kathleen_Wahlbin
Scribe
Kim

Contents


<trackbot> Date: 12 November 2015

<Kathy> http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation

Kathy: I updated github, working on guideline 2.5, 2.5.1 breakthrough on last call
... key is that we added it remapped the touch gestures
... two potential techniques – using standard One Touch controls, providing touch access for custom controls, and two failures. That's where we left off.
... any questions or comments on that or concerns with that direction

David: we'll probably need to define system assistive technology at some point

Kathy: one of the things we did in the last call is we took out the pointer, but when I was updating the draft – in the guideline we have touch and pointer, but nothing else that talks about pointer – should we change the guideline to be just touch

David: I'd leave that decision for later – just leave it in and put it in that if we don't have anything that applies

Jan: I like the word pointer in there

Kathy: as we go through this we may want to think a little bit about where pointer fits in and what we want to do
... last thoughts on 2.5.1 before we move onto the next one

Jan: Intel used a system with a front facing camera to watch where your head was moving and you could use that as a head mouse – mouse interface always in android, been added to Windows, blackberry has it. Head mouse could be a new assistive technology
... missed spot in okay to – nondisabled people the only ones using a mouse so were not going to talk about it at all, but there are plenty of people using mouse emulators and they really appreciate an interface where things are easy to get to with the mouse

Kathy: has anyone played around with a Bluetooth mouse on android?
... do we want to change 2.5.1 at all – we took out pointer, do we need to put it back in

David: I almost want to say touch/pointer

Kathy: but Poynter doesn't remap touch gestures
... any discussions about mouse in WCAG

David: one things that circumvented was mouse keys and we didn't identify barriers at the time. In 10 years I don't remember any email that we got from anybody who had a problem with the mouse and needed some kind of success criteria to deal with it – reluctance to put something in for something that didn't appear to be a barrier

Kathy: but that's change now with the new technology Jan was talking about

David: there could be some dumb thing and authors doing that's preventing the mouse from working properly with an assistive emulator, but I haven't heard of any

Jan: I have a contact who works with a lot of people in that situation who work with head mice – I will talk to them and see if I can get some use cases

David: asked them also about the prevalence of using mouse keys

<jon_avila> +1 to Kim

Kim: speech input mouse emulators are generally very bad. very slow and not practical. I'm wondering how fast other emulators are.

David: Patrick had a whole list of JavaScript calls that touch was activating – want to understand that

<Jan> JR: Quick test of TalkBack with mouse...works with one click to focus items (TB reads), then double click to activate.

<jon_avila> http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-events

2.5.2

Kathy: we may want to use the same technology here – change to system

David: what Jan calls a reverse trap – you can't close it

Kathy: on-screen keyboard is often a problem – you can't close it
... if we were going to add in the reverse to that what would we do. It's also very long can we simplify to make it shorter
... no comments in the survey

Jon: we are thinking swipe gestures because that's what everybody's using right now, but potentially – explore by touch I have a similar problem. I wish we could generalize it beyond swipe gestures

<Jan> JR: CORRECTION: With Talkback on, Mouseover puts on TB focus, single mouse click (on the item) activates (and TB swipe gestures don't work). So not really useful for blind user, but could be helpful for a person needing literacy support.

Jon: an iOS there is a direct touch – you can do a signature. Go directly to app instead of to voiceover. I could imagine in that situation to get out of that you would have to touch somewhere else on the screen and not within that touch area. This is not web-based but I imagine that at some point that ability would be available through the web as well

David: it's not like what we had in the old days of the keyboard trap. In this situation where you are on a mobile device you kind of know where you are when you touch on something – is it a problem?

Jon: if it happened all the time it would be but if it happened occasionally then maybe it's acceptable. Not permissible if every control had that problem, would make it difficult to use. This relates to a point it brought up in the survey – swipe navigation can be different than Explorer by touch. Might be in a swipe order but might not be detectable by exploration

David: that may be a failure
... I would say that that equally punishes everybody because nobody's gonna see it

Jon: I'm thinking of a case where there is a checkbox…
... physical checkboxe is on screen so can see it but can't swipe to it

<Detlev> Hi, I've just joined.

David: it's in this way border but it's not in the touch order. If it's visible on the screen, are you saying that maybe the screen reader can hear it even if you put your focus on it

Jon: on-screen just a span that takes the touch events but does not handle the keyboard accessibility, that's handled by the child element which is offscreen. Commonly used in custom controls

<Kathy> \me Detlev we are discussing 2.5.2 http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation

<Detlev> Cheers!

David: can't a person using voiceover touch on that physical element, just as a sighted person would and they would hear it spoken when they touch it

Jon: in theory because it's not accessible – doesn't have a name. If you add that then you have duplicate. Generally it's not seen by the technology the way it's coded. This is an author issue
... I can send an example. I thought it was related.

Alastair: focus appeared over the top of the URL and as soon as someone double tapped on it picked up the underlying browser functionality rather than the page functionality. Appears where you have a scrollable div through CSS. Voiceover goes underneath to where it believes that content should be

David: the new quick ref is actually using that exact technology
... Divs that are scrollable.

Alastair: if you do explore by touch you are nowhere near what you think you are near

<David> check this

<David> http://w3c.github.io/wai-wcag-quickref/

<David> infinite scroll on Iconic framework doesn't

Marc: how is this different from those new widgets that do the infinite scroll that you can't get to work – gray area between where it's a swipe trap

Kathy: does pass-through gesture work

David: pass-through gesture is really broken

Kathy: capture what we are talking about – even rough success criteria around that, it's related to this but it doesn't exactly fit in here

David: using the same language as 2.5.1, touch events that are discoverable that can be activated by voice over are in the position that they were previously – something like that

<Kathy> Touch events that are discoverable and activated by touch are in same position

Detlev: cognitively you have an idea of where something is on the page, but in reality it's different
... we need a simplified example set up to look at

<Kathy> Touch events that are discoverable and activated by touch are in same position on the screen.

Kathy: Jon has some examples

Alastair: that's what I'm finding hardest about mobile navigation with voiceover and talkback – you are taken to a distant place a lot than where you expect to be. It must be incredibly difficult if that's your only mechanism to navigate

<Kathy> Touch events that are discoverable and activated by touch remain in a logical position on the screen.

Detlev: touch events apply to actionable elements, swipe go to content all continent text content and so on so we are dealing with two different things

Alastair: in my case you put your finger on it and it disconnected from the whole page and went into the phone which was even more annoying

David: can you grab that code and throw up an example

Alastair: I'll try

David: logical is difficult language
... logical is same order on the page

Jon: meaningful sequence

Detlev: meaningful sequence applies to all elements including text which is not actionable – we need to keep those separate I think

Alastair: it's when you're going down swipe swipe swipe through voiceover, for example you want it to be predictable by the user. It's not very testable however

Alan: view controllers just aren't done right so hidden content is actually being selected – is that the problem?

Kathy: no

Alastair: problem: phone, voiceover, Safari terms and conditions webpage like a banking website. Box was terms and conditions, scrollable div, checks boxes. You go into it, voiceover didn't read out because it was taking directive but that doesn't matter.. Swipe swipe swipe enter scrollable div. The official focus and focus for voiceover continues down the page out of the box – right down...
... the page. Then when you try and get to the checkboxes, focus reengage at the top of the screen at URL and so double tap engaged URL box rather than the web content

David: CSS nonmodal dialog box, didn't put focus in dialog box…

Alastair: not dialog box, just scrollable div
... because trying to find checkboxes, focus got kicked back to the top of the page. Double tap disastrous result

Detlev: did the checkboxes come after the div?

Alastair: yes

David: textbook example of failure

Alastair: I will try and get one

David: what about touch events that are visually present on the screen are programmatically on the screen also

Kathy: I think people will say what you're talking about?
... let's come back to it
... in the last 10 minutes that we have I would like to take a look at 2.5.2, no swipe traps, see if we can do adjustments and put techniques or failures for this

Alastair: banking websites – putting a number where it sends you from one box to the next, depending on how they do that and how the focus shifts, in effect the focus may stay with one of those boxes instead – I'll check that

Kathy: I've had situations where you can't touch and you can't swipe out of something and those have been more on the app side than the web side

Detlev: ARIA hidden equals true, could that be situation where you are stuck on that, some overlay which doesn't get any touch pass through and you are stuck with that element and you can't close that box for example
... pop-up which has a close button or that button doesn't work – trying to think of some situation where you just couldn't get out of it by swiping
... is that covered already 2.1.2

Alastair: focus past the close button, go down to the bottom of the page and don't know ultimately rather they would return, because when you go down to the bottom of the page you would expect to find those things.

Detlev: get lost in the page background which might not be visible?

Alastair: window pops up, take and pass that and when they do swipe swipe swipe in mobile they are not able to explore the content on the page because it's covered and they are not able to get to the close button

Detlev: you aren't stuck but you don't know to get back to the swipe button so it's different

Alastair: the question is whether they take the entire page
... we could look around for next week for decent examples.

Kathy: a good take away for this week – we need to think about areas where we need to address this – better to come up with techniques and failures

<Detlev> Modal example with aria-hidden for page background: http://www.3needs.org/en/testing/code/role-dialog-3.html

Detlev: put examples needed in meeting request?

face-to-face meeting

<Kathy> https://www.w3.org/2002/09/wbs/35422/WCAGF2F/

Kathy: face-to-face meeting will be in conjunction with the task forces. I think it's important that we get together and talk about what's going on in each of the different extensions – potential conflicts, crossover, things that may not coexist together with another extension. And so were looking at doing a face-to-face. There's a survey I put in the agenda if you can go in and take that...
... survey so that we know what conferences might work or other suggestions – we will look at that and try to get a face-to-face together with everybody
... when option is CSUN
... same survey as WCAG

<alan> That is one option is CSUM

<alan> CSUN

Kathy: Another good option is TPAC
... we are going to continue trying to get the touch guideline success criteria and techniques and failures defined next week. If you have examples for any of the ones in the guideline feel free to send those around to the group.

<jon_avila> I will not be available next week.

Kathy: I'll be at the Accessing higher ground conference next week, Kim will be here. We won't have a meeting on the 26 for Thanksgiving

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/12 17:06:27 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: Kim
Inferring Scribes: Kim
Default Present: Kathy, Kim, jon_avila, Alistair, marcjohlic
Present: Kathy Kim jon_avila Alistair marcjohlic 1 Jan Detlev David
Found Date: 12 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/12-mobile-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]