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

Timestamps are in UTC.

15:49:38 [RRSAgent]
RRSAgent has joined #mobile-a11y
15:49:38 [RRSAgent]
logging to http://www.w3.org/2016/03/03-mobile-a11y-irc
15:49:40 [trackbot]
RRSAgent, make logs public
15:49:40 [Zakim]
Zakim has joined #mobile-a11y
15:49:42 [trackbot]
Zakim, this will be WAI_MATF
15:49:42 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
15:49:43 [trackbot]
Meeting: Mobile Accessibility Task Force Teleconference
15:49:43 [trackbot]
Date: 03 March 2016
15:50:05 [Kim]
chair: Kathleen_Wahlbin
15:53:16 [Kim]
agenda+ Review assignments http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
15:53:18 [Kim]
agenda+ 2.5.2 proposed Understanding text https://w3c.github.io/Mobile-A11y-Extension/#swipe-trap
15:53:19 [Kim]
agenda+ Revisions to 2.5.3, M029 - https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3 https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029
15:53:21 [Kim]
agenda+. Look at proposed 2.7 https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Speech_Input_Accessibility_%28Guideline_2.7%29
15:53:22 [Kim]
agenda+ Next steps – next meeting March 10
15:56:16 [Kim]
regrets+ Alistair, Alan
15:57:47 [Henny]
Henny has joined #mobile-a11y
15:59:27 [chriscm]
chriscm has joined #mobile-a11y
16:01:20 [Kathy]
Kathy has joined #mobile-a11y
16:01:57 [marcjohlic]
marcjohlic has joined #mobile-a11y
16:03:03 [Jatin]
Jatin has joined #mobile-a11y
16:05:07 [Kim]
zakim, take up next
16:05:07 [Zakim]
agendum 1. "Review assignments http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments" taken up [from Kim]
16:05:37 [jeanne]
present+ jeanne
16:05:43 [Kim]
Kathy: any questions on assignments or information for the group
16:05:48 [Kathy]
present+ Kathy
16:06:03 [Kim]
Marc: time opening up in the next few weeks
16:06:56 [Kim]
Chris: asking about failure template
16:06:59 [jon_avila]
jon_avila has joined #mobile-a11y
16:07:04 [jon_avila]
present+jon_avila
16:07:20 [Kim]
Kathy: default template – also in the wiki, also look at some of the other failures
16:07:26 [Kathy]
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
16:07:54 [Jatin_]
Jatin_ has joined #mobile-a11y
16:07:57 [Kathy]
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Failure_of_2.5.3
16:08:38 [Kim]
Kathy: here's an example – you can use this general format
16:08:50 [Kim]
Jeanne: that's a really good example of a completed one
16:09:19 [Kim]
Kathy: any other questions comments on assignments
16:09:22 [Kim]
zakim, take up next
16:09:22 [Zakim]
agendum 2. "2.5.2 proposed Understanding text https://w3c.github.io/Mobile-A11y-Extension/#swipe-trap" taken up [from Kim]
16:09:54 [Kim]
Kathy: did you have a chance to read – any comments or changes
16:11:11 [Kim]
Jon: most mobile screen technologies also allow Explore by touch – is this acceptable
16:11:58 [Kim]
Chris: no. swipe gestures would not be accessible to someone using a switch control
16:12:06 [Kim]
Jon: what would be acceptable for a developer to do
16:12:24 [Kim]
Chris: are you suggesting we need to put restrictions on what the alternative methods are?
16:13:31 [Kim]
Jon: potentially yes. Prevents switch control from moving to all. IOS and VoiceOver you can move the screen reader focus with UI kit. It's potentially a bigger issue with voiceover. I would think it would be much more difficult with switch control for developer to do such a thing
16:14:02 [Kim]
Kathy: you're commenting on the actual text of and success criteria 2.5.2 – looking at the understanding, but can also look at the actual text
16:14:32 [Kim]
Chris: right under 2.5.1 – is this even focusing on the AT being on?
16:15:03 [Kim]
Kathy: first part of it is when touch is modified by the platform – AT and touch
16:15:18 [Kim]
Jon: switch user is not using a swipe gesture, switch control is automatic
16:15:59 [Kim]
Chris: were talking about going to the next item – whether you're activating via swipe or a switch obviously for the swipe gesture user has easy ways of getting around the use of that but not for the switch user – separate action
16:16:31 [Kim]
Jon: explore by touch – you go past and then you're stuck again
16:16:46 [Kim]
Kathy: recommended changes? To success criteria or add to understanding?
16:17:51 [Kim]
Jon: language is similar to 2.1.2 – make sense. Keyboard, that's easy. Problem on a mobile device touch gestures might not – way around it is a draw circle, of course that might not fulfill other criteria.
16:18:02 [Kim]
Jon: preserve users ability to not miss content
16:18:23 [Kim]
Chris: note, explore by touch is not an acceptable solution or something like that would clarify
16:18:50 [Kim]
Jon: that's one example, but we need something in the actual success criteria that doesn't say Explore by touch but makes it stronger
16:19:10 [Kim]
Chris: could also related to the focus order trap under the traditional guidelines – 2.1.2
16:19:32 [jeanne]
Propose: Swipe gestures are useful for displaying dynamic content. Giving focus to dynamic content via a swipe gesture also needs a gesture or method to move focus back to prior content — either by swiping to return or by informing the user of the method needed to return. These methods must work with assistive technology. Explore by touch is not a valid solution, because the user can
16:19:32 [jeanne]
then miss content without knowing it was missed. This success criterion is similar to WCAG 2.1.2 No keyboard trap.
16:20:34 [Kim]
Jeanne: proposal for understanding
16:21:21 [Kim]
Jon: worried you can interpret the success criteria otherwise
16:21:51 [Kim]
Kathy: what if we took off the part about moving focus away
16:23:36 [Kim]
Chris: knowing AT is on for this – if you are using swipe gestures to activate some type of content, when the AT is on you are not going to be able to explore in the same way but the wording– swipe is going to be captured by AT and not make it a violation of something else and also a violation of 5.2
16:24:33 [Kim]
Chris: swipe gesture getting to the list without AT on – what is getting to the list with AT on. The wording is confusing because if you know that and are doing assuming the AT is on how do these swipe gestures get captured
16:24:59 [Kim]
Jon: I think we were trying to say is with the AT on is possible to get into a trap
16:25:30 [Kim]
Jon: maybe it's swipe gestures that's the problem
16:25:39 [Kim]
Chris: it's not swipe gestures that's an issue it's just focusing anything in any way
16:25:46 [Kim]
Chris: you have to separated from the touch
16:26:10 [Kim]
Kathy: if we took out using swipe gestures
16:26:58 [Kim]
Chris: if we remove swipe gestures from the equation is completely covered by 2.2.1 keyboard trap except some of those touch specific solutions. All of the issues we talked about our colored by keyboard trap. Problem is with a touchscreen you can do this touch navigation thing to get around some of these things. But we want to do is say hey that's not a solution because we have users who are...
16:27:00 [Kim]
...still relying on keyboard
16:27:34 [Kim]
Marc: would we have to still keep it separate. There's no keyboard trap because if you have a touch screen on your desktop you can find a way out – is there one specific to mobile rather than adding into existing
16:28:06 [Kim]
Chris: the way in which we need to separate it isn't creating a new criteria, but saying these keyboard traps or let's call them navigation traps – that touch to explore things that touch screens allow is not a solution
16:28:39 [Kim]
Chris: take the word keyboard out of keyboard trap, call it navigation trap and how is the criterion different
16:29:18 [Kim]
Jon: trying to make more strict – not just keyboard. Sometimes Explore by touch is not the optimal solution but maybe isn't going to happen very often, maybe it's an edge case
16:29:39 [Kim]
Kathy: do we have a failure under the keyboard trap? Keyboard is keyboard interface it doesn't mean the actual physical keyboard
16:30:35 [Kim]
Kathy: it looks like the WCAG extension maybe 2.1 rather than extension – we have to get away from thinking we necessarily need something altogether separate. If what we come down to saying is there's really nothing different except we want to assure certain things are done then maybe we can add something to the understanding of keyboard trap one to address mobile and then put the failure
16:30:43 [Kim]
Chris: that makes more sense to me
16:31:17 [Kim]
Jon: if that works, if we could do that that's fine with me – if we can enhance the current success criteria in the new version of WCAG by having a failure
16:31:58 [Kim]
Jeanne: I would recommend someone write this up as a persuasive argument that we need a WCAG 2.1 rather than an extension
16:32:25 [Kim]
Chris: I'm not sure what that process you outlined was but I'd be happy to do it
16:33:30 [Kim]
Chris: it's not that there aren't mobile considerations, it's just that the mobile considerations can be expanded on what's already there
16:34:00 [Kim]
Chris: completely generalize it – wording would become no navigation trap
16:34:28 [Kim]
Marc: generalizing 2.1.2 – I like the no navigation trap. I like the proposal Kathy did earlier
16:34:59 [Kim]
Chris: we can keep swipe out of the base text and examples, failures use swipe wording. Becomes a more general thing, more obvious about how that would apply
16:35:39 [Kim]
Kathy: we have a statement in the understanding right now referring to 2.1.2 no keyboard trap, if we document what we are talking about now we can use this as an example as to how we are going to do the extension
16:36:23 [Kim]
Kathy: if we work on in this meeting coming up with language about why it's different – Jon's point out if I the actual success criteria a little bit. It may not roll into 2.1.2, but at least we've documented why we've added it here – what is actually different are missing, why we need to change 2.1.2
16:36:37 [Kim]
Jon: I think as we document our concerns if it gets rolled into 2.1.2 that's fine later
16:37:01 [Kim]
Kathy: the somebody want to suggest the changes to the success criteria and is someone want to take a stab writing about what is different – why we are proposing this
16:37:26 [Kim]
Jon: I can do the success criteria one – was consensus to leave swipe in or take it out
16:37:50 [Kim]
Kathy: I think and says this was taking it out that focus can be moved, but I left swipe gestures in there as a method of moving focus away
16:37:57 [Kathy]
2.5.2 No Swipe Trap: When touch input behavior is modified by platform assistive technology so that touch focus can be moved to a component of the page using swipe gestures, then focus can be moved away from that component or the user is advised of the method for moving focus away.
16:38:28 [Kathy]
2.5.2 No Swipe Trap: When touch input behavior is modified by platform assistive technology so that touch focus can be moved to a component of the page, then focus can be moved away from that component using swipe gestures or the user is advised of the method for moving focus away.
16:38:37 [Kathy]
2.5.2 No Touch Trap: When touch input behavior is modified by platform assistive technology so that touch focus can be moved to a component of the page, then focus can be moved away from that component using swipe gestures or the user is advised of the method for moving focus away.
16:38:46 [Kim]
Jon: do we want to say no touch trap – do we want to keep Swype in the name
16:39:18 [Kathy]
This success criterion is similar to WCAG 2.1.2 No keyboard trap.
16:39:29 [marcjohlic]
"This success criterion is similar to WCAG 2.1.2 No keyboard trap, however it expands beyond simply keyboard input and applies to all methods of input and navigation including, but not limited to, keyboard, swipe gestures, ... "
16:39:31 [Kim]
Action: Jon 2.5.2 SC
16:39:31 [trackbot]
Created ACTION-41 - 2.5.2 sc [on Jonathan Avila - due 2016-03-10].
16:40:20 [Kim]
Action: Chris document how this is different from 2.5.2 – add text after
16:40:20 [trackbot]
Created ACTION-42 - Document how this is different from 2.5.2 – add text after [on Chris McMeeking - due 2016-03-10].
16:41:09 [Kim]
Marc: just put suggestion in IRC about action 42
16:41:46 [Kim]
Henny: I completely agree – will add clarity referencing back
16:43:15 [chriscm]
... similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all linear navigation methods and compensates for touch specific failure criteria.
16:43:25 [Kim]
Jon: I'm a little hung up on taking focus away part – touch gestures or navigation gestures
16:44:05 [Kim]
Kathy: can we put an example in
16:44:45 [Kim]
Kathy: we have to define linear navigation methods. If we added that into the success criteria rather than swipe gestures
16:44:59 [chriscm]
... similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all linear navigation methods and compensates for touch specific failure criteria. For example, solutions relying on a users ability to use a touchscreen to escape such a trap are still failures under this criteria.
16:45:28 [Kim]
Kathy: that's a point for the understanding document to – key point is user needs to know where they are
16:46:11 [Kim]
Kathy: if you use Explorer by touch you've lost where you are on the screen and you might have to do more to figure out where you are. Fundamental point between keyboard and touch – touch can be random
16:46:21 [chriscm]
... similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all sequential navigation methods and compensates for touch specific failure criteria. For example, solutions relying on a users ability to use a touchscreen to escape such a trap are still failures under this criteria.
16:46:35 [Kim]
Kathy: if you are relying on a single method like explore by touch, same keyboard trap over and over again because you don't know where you are
16:46:47 [Kim]
Chris: did you touch the top of the page of the bottom of the page – you're not sure
16:46:58 [Kim]
Kathy: because you don't know context
16:47:47 [Kim]
Kathy: clarify the example?
16:47:49 [jeanne]
UAAG uses Sequential Navigation. The UAAG definition of sequential navigation commands is: sequential navigation commands (sometimes called "logical navigation commands" or "linear navigation commands"): Commands that move focus forwards and backwards through a list of items. The element list being navigated can be the list of all elements or just a subset (e.g. the list of headers, the
16:47:49 [jeanne]
list of links).
16:48:56 [Kim]
Jon: would you prefer reading order or focus order – there could potentially be differences
16:49:04 [Kim]
Kathy: I think since were talking or navigation methods focus might make more sense
16:49:07 [jeanne]
+1 for focus order
16:49:16 [jon_avila]
No Touch Trap: When touch input behavior is modified by platform assistive technology and focus can be moved to a component, then focus can be moved past that component using sequential navigation gestures of assistive technology or the user is advised of the method for moving focus to the next sequential item in the focus order.
16:49:29 [chriscm]
... similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all sequential navigation methods and compensates for touch specific failure criteria. A solution may be to rely on touch-to-explore features of mobile ATs to escape such a trap. This is still a failure under this criteria.
16:49:32 [Kim]
+1 for focus order
16:49:38 [chriscm]
+1 for focus order
16:50:06 [Henny]
+1 for focus order
16:50:11 [jeanne]
+1 for chris' proposal
16:50:45 [jeanne]
+1 Jon's proposal
16:50:50 [Kim]
Jon: I didn't say explore by touch, but I said it has to go to the next thing
16:50:55 [chriscm]
+1 jon's proposal
16:51:08 [Kim]
Jon: bottom of page and you could navigate backup
16:51:26 [Kim]
Jeanne: I don't know of any user agent the doesn't wrap in the focus order
16:51:28 [Henny]
+1 for Jon's proposal
16:52:41 [Kim]
Kathy: if it's more of a user agent thing are we worried about wrap in focus order
16:53:13 [Kim]
Jon: wonder if we could put something like prior and next when applicable
16:53:23 [Kim]
Kathy: add to understanding, make sure success criteria isn't so complex
16:53:51 [Kim]
Kathy: can we change it so we don't have next in there – logical item in focus order?
16:54:01 [Kim]
Jon: past and next – past is maybe a little bit better
16:54:02 [chriscm]
... similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all sequential navigation methods and compensates for touch specific failure criteria. A solution may be to rely on touch-to-explore features of mobile ATs to escape such a trap. This is still a failure under this criteria, because the next sequential item may be offscreen, an explore by touch gesture may cause users to get lost on the page, or the user may be relying on
16:54:02 [chriscm]
other means of sequential navigation such as a keyboard or switch control.
16:56:01 [chriscm]
... similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all sequential navigation methods and compensates for touch specific failure criteria. Relying on touch-to-explore features of mobile ATs to escape such a trap is still a failure under this criteria, because the next sequential item may be offscreen, an explore by touch gesture may cause users to get lost on the page, or the user may be relying on other means of sequential
16:56:01 [chriscm]
navigation such as a keyboard or switch control.
16:56:17 [marcjohlic]
+1
16:56:19 [jon_avila]
No Touch Trap: When touch input behavior is modified by platform assistive technology and focus can be moved to a component, then focus can be moved away from component using sequential navigation gestures of assistive technology or the user is advised of the method for moving focus away in sequential focus order.
16:59:10 [Kim]
Marc: does it really need to be based on assistive technology being on
16:59:28 [Kim]
Jon: I think it would be covered already under 2.1.2
16:59:34 [Kim]
Kathy: maybe we should add that to the understanding
17:00:02 [Kim]
Kathy: any other suggestions or changes?
17:00:10 [jeanne]
+1
17:00:14 [chriscm]
+1 all looks good
17:00:22 [Kathy]
+1 to Chris & Jon's proposed cahnges
17:00:25 [jon_avila]
+1 to SC and understanding
17:00:27 [Kim]
+1 Chris and John's proposals
17:00:30 [marcjohlic]
+1 to both the revised Understanding text and to the Success Criteria
17:00:37 [Henny]
+1 to Chris and Jon's proposal, nice work!
17:01:43 [Kim]
Kathy: we will continue next week on the next items. A number of discussions, if you haven't read I recommend going through 2.5.3 versus back and forth with Patrick and Jon on that
17:02:02 [Kim]
Resolution: revised Understanding text and to the Success Criteria
17:02:43 [jeanne]
s/Understanding text and to the Success Criteria/Understanding text and to the Success Criteria of 2.5.2 No Swipe Trap to No Touch Trap
17:03:20 [Kim]
RESOLUTION: Understanding text and to the Success Criteria/Understanding text and to the Success Criteria of 2.5.2 No Swipe Trap to No Touch Trap
17:03:51 [jeanne]
rrsagent, make minutes
17:03:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/03/03-mobile-a11y-minutes.html jeanne
17:04:19 [jeanne]
rrsagent, make logs public
17:05:56 [jeanne]
zakim, close action-41
17:05:56 [Zakim]
I don't understand 'close action-41', jeanne
18:06:54 [Kim]
Present+ Kim, Henny, Chris, Marc, Jatin
18:07:08 [Kim]
Regrets+ David
18:07:28 [Kim]
rrsagent, make minutes
18:07:28 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/03/03-mobile-a11y-minutes.html Kim
18:11:27 [Kim]
rrsagent, bye
18:11:27 [RRSAgent]
I see 2 open action items saved in http://www.w3.org/2016/03/03-mobile-a11y-actions.rdf :
18:11:27 [RRSAgent]
ACTION: Jon 2.5.2 SC [1]
18:11:27 [RRSAgent]
recorded in http://www.w3.org/2016/03/03-mobile-a11y-irc#T16-39-31
18:11:27 [RRSAgent]
ACTION: Chris document how this is different from 2.5.2 – add text after [2]
18:11:27 [RRSAgent]
recorded in http://www.w3.org/2016/03/03-mobile-a11y-irc#T16-40-20