See also: IRC log
Kathy: focus on guidelines
today.
... would like to have people identify techniques for 2.5.1
Kathy: publishes a draft ideally before CSUN – techniques especially within the touch and pointer area, some of that finalized by than. That involves getting feedback from WCAG
<david> link to the current draft pls
Kathy: input from more people by
publishing to mailing list etc.
... that's where we are hoping to go – any questions
Detlev: open questionnaire again?
Kathy: questionnaire is now open
<Kathy_> http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation
<david> can people not talking mute
Kathy: examples sent around for 2.5.2 swipe traps
<Detlev> Can you post the link again to Alistairs example?
David: reverse trap the big problem?
Kathy: scrolling div problem, and
Alastair comment on scrolling div
... I'm not 100% clear on whether this is an issue in iOS or
just HTML
Jon: one example it comes to mind is an infinite carousel – you can swipe through all the items and instructions that say swipe outside the carousel to move the focus away from it. Does that meet that requirement or would we see that as a failure?
Kathy: since they are advised that they could move away as long as they could do that with the screen reader turned on the only question is what it actually work with a keyboard to or is it only touch to do it
Jon: exactly and what if there's content after the carousel – you would have to swipe backwards to go through it and you could end up in the carousel again and have to touch to get out of it again – very kludgy
Kathy: if touch outside the carousel are you wherever you touch or outside the carousel
Jon: with voiceover it's wherever you touch
David: trying it
Kathy: based on that kind of behavior, do we need to change 2.5.2?
Jon: there must be a predictable way – touching randomly on the screen not enough
Kathy: should we take out user is advised of a way of moving focus away
Jon: just needs to be
qualified
... looking at the corresponding keyboard one it has the same
problem – it assumes that if you move away you would end up on
the next focus will item but it doesn't say that
Kathy: with keyboard it's a little more predictable – going through the page as opposed to with touch you could touch anywhere
<Detlev> Can't hear you David...
David: what happens if you tab – you only have a keyboard you don't have a mouse
Jon: you'd be tabbing through
everything so you would never get out of it, but you could set
up a keyboard binding. That wouldn't work for touch user
... are we pushing for keyboard accessible for voiceover user
or touch accessible as well
... it would be similar if there was a footer on the page and
you could never reach the footer because of an infinite
scroll
David: it sounds like a big issue to me
Kathy: any examples that people know of or are these things were going to have to set up ourselves?
David: I think we need to find
them in the wild. Olympic Canadian committee example, you
couldn't get to the infinite scroll, it was the opposite
problem
... maybe we can all take an action item to look around for
infinite scrolls that don't work
Kathy: I ran across an issue with touch access – scrollbar to get information but on mobile the scrollbar was cut off on the right hand side so you couldn't use it. Nobody can use it
Detlev: example that puts aria hidden on the page background preventing you from accessing – sent one example to the list that I constructed – page background doesn't get focus anymore once the page has been selected – not sure it's a realistic example
Kathy: after the dialogue closes you can access it?
Detlev: if you could get out to the browser chrome you could then go elsewhere
Kathy: it's not exactly a swipe trap, not sure where that fits
Marc: example with voiceover on
no longer able to scroll
... AT is interfering with gesture
David: confirming that doesn't work with voiceover on. I can view everything offscreen, but it doesn't scroll interview. I'm on the screen but on the screen all I see is up to row 12
Kathy: messed up for anyone with low vision
David: three finger swipe down doesn't scroll it
Kathy: how about using pointer events to change the position
<marcjohlic> https://github.com/cubiq/iscroll
David: Marc, I think this is a wonderful example we need to figure out why it doesn't work
Kathy: any other examples we
should be looking at
... Marc, you mentioned the developer wasn't interested in
trying to figure this out
Marc: we told our folks to use a different plug-in instead
Kathy: can you send a note on the mailing list – quite a few people who are watching us are more technical and may be able to figure that out
Detlev: something like the 4 finger swipe – assume that this is available – get to bottom of page, then swipe backwards
David: it's an escape, but it sounds like a hack – we wouldn't want people to have to do that…
Detlev: is that something we need to take into account, if there are gestures that are documented
David: we have lots of precedents for failures for things that just make it difficult – it doesn't have to be a complete failure to be a failure
Kathy: with the I scroll can you
do a passthrough gesture to make it work
... so we'll do more research, Marc you will send that out on
the mailing list
... are there any techniques or failures we can list under here
right now
David: 2.5.1 example
Kathy: not even keyboard accessible
Jon: if it could be made keyboard accessible, maybe it would work
Kathy: no keyboard handlers on
that
... anything else for 2.5.2?
Kathy: Finger lift triggers event. No comments on the survey on this one. Thoughts? Techniques or failures that would go under this one?
Detlev: this is from the BBC mobile accessibility guidelines – they have a checkpoint for that. It's a no screenreader active kind of technique
Kathy: we should look at the examples under the BBC
David: we have to define what a long press is
<david> link to bbc
<david> ?
Marc: if you kept pressing but then move your finger away I wasn't sure how to define that – lifting your finger would be moving away also
<Kathy_> http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/focus/touch-events
Detlev: compare points. Same as usability function – only activate on mouseup – same thing
Jon: in iOS use touch location, use final touch location. That says this is an issue.
Kathy: is this a problem for all users
Jon: worse for people with disabilities, but in theory yes
Kathy: looking at BBC examples, failure for touchstart gesture – should we have something that specific to Ontuchstart and keydown
David: haven't heard of that is a problem
Jon: with touch it's a bigger issue touch location has a bigger influence
David: what we have heard in the
last couple of days is we can't change WCAG – we can't make new
failures based on new technologies and then map to 1.3.1 or
something, at least that seems to be the sentiment. Can in
extensions.
... this is the place to make new requirements for WCAG
extension. Won't get it into the main document
Detlev: Can meet the descriptive link success criteria by having a heading above the link – this technique is no longer under sufficient, would fail now
Jon: JAWS supported that but other assistive technologies did not
David: I think the extension is a good place to put it
Kathy: so we want to put an
Ontouchstart failure in here. What about key down
... would that fall here or under keyboard
Jon: we have to qualify this – could be potential situations where it may be acceptable – maybe on-screen keyboard. I'm worried if we don't have some kind of exception for it…
Worried that there some situations that could make this a failure
David: exception, drawing, but drawing doesn't do anything on touching down anyway
Kathy: if we were going to try to restrict this further we would need an example of where this would not work
Jon: what about icons – touch and
hold, long press move icon around.
... you can lift your finger to cancel it so add something like
unless event has been canceled. If you hold and move your icon
if you just release it it goes back to normal
Kathy: unless the event can be canceled. Or do we need to be more specific than that?
Jon: depends what the definition of canceled is? I be fine putting canceled and for now – cancel is different from undo.
Kathy: so how can you cancel drag-and-drop
Jon: in this specific case – unless you start moving the icon around, an iOS it reorders itself and so you can't put it back to where it was
David: hit the home button
Jon: home turns off the shaky movement, but doesn't but the icon back where it was
Kathy: maybe we have an exception
for drag-and-drop?
... you could have a failure ontouchstart and drag-and-drop
would be an exception for that – is that going to be a problem
for failure… We could have a technique on touch and a failure
for ontouchstart
Jon: I think we should have failures for all
Kathy: propose a title?
Marc: the BBC language is kind of close – "removed from a control" I don't know if removed is right – needs intention
<david> Touch events are only be triggered when touch is removed from a control
<jon_avila> Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location
Kathy: the BBC is written in a different tone than WCAG
Kathy: I want to start writing up
techniques and failures. We have two, does anyone want to take
an action – we can do it collaboratively too
... sometime in the next month
Jon: I can do the failure – can get it to you after Christmas
Kathy: target is first week in January, John you have the failure for 2.5.3
David: need definition for long press
Detlev: is it supposed to be a general technique or an HTML specific technique providing access for custom controls
<jon_avila> long press: pressing and holding on an item for a short time, usually opens additional menus or acts as a click-and-drag function
Kathy: we are doing HTML, not doing native apps right now so this would be HTML
Detlev: would be useful to have a test full of good and bad examples – difficult to relate to without it
Kathy: next week maybe we can put some concrete examples to them, then start working on them
David: pput me down for writing techniques for 2.5.3
Kathy: trying to get touch and pointer fleshed out as much as we can so when we go to
publish a draft we've got some concrete stuff that's not out there right now for mobile. We've done a lot of great work in this area, now put examples around it.
Detlev: I can draft providing access for touch controls
Jeanne: what David proposes a new success criteria for drag-and-drop
Kathy: that's a technique and failure under 2.5.3
Marc: will tackle a general
failure around functionality not being available when AT is
activated
... writing out full technique or just coming up with things
that would fit under it?
Kathy: whole technique
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 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 Present: Kim jon_avila Kathy jeanne David Jeanne Detlev Marc Jon Regrets: Henny Found Date: 03 Dec 2015 Guessing minutes URL: http://www.w3.org/2015/12/03-mobile-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]