15:49:38 RRSAgent has joined #mobile-a11y 15:49:38 logging to http://www.w3.org/2016/03/03-mobile-a11y-irc 15:49:40 RRSAgent, make logs public 15:49:40 Zakim has joined #mobile-a11y 15:49:42 Zakim, this will be WAI_MATF 15:49:42 I do not see a conference matching that name scheduled within the next hour, trackbot 15:49:43 Meeting: Mobile Accessibility Task Force Teleconference 15:49:43 Date: 03 March 2016 15:50:05 chair: Kathleen_Wahlbin 15:53:16 agenda+ Review assignments http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments 15:53:18 agenda+ 2.5.2 proposed Understanding text https://w3c.github.io/Mobile-A11y-Extension/#swipe-trap 15:53:19 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 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 agenda+ Next steps – next meeting March 10 15:56:16 regrets+ Alistair, Alan 15:57:47 Henny has joined #mobile-a11y 15:59:27 chriscm has joined #mobile-a11y 16:01:20 Kathy has joined #mobile-a11y 16:01:57 marcjohlic has joined #mobile-a11y 16:03:03 Jatin has joined #mobile-a11y 16:05:07 zakim, take up next 16:05:07 agendum 1. "Review assignments http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments" taken up [from Kim] 16:05:37 present+ jeanne 16:05:43 Kathy: any questions on assignments or information for the group 16:05:48 present+ Kathy 16:06:03 Marc: time opening up in the next few weeks 16:06:56 Chris: asking about failure template 16:06:59 jon_avila has joined #mobile-a11y 16:07:04 present+jon_avila 16:07:20 Kathy: default template – also in the wiki, also look at some of the other failures 16:07:26 https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments 16:07:54 Jatin_ has joined #mobile-a11y 16:07:57 https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Failure_of_2.5.3 16:08:38 Kathy: here's an example – you can use this general format 16:08:50 Jeanne: that's a really good example of a completed one 16:09:19 Kathy: any other questions comments on assignments 16:09:22 zakim, take up next 16:09:22 agendum 2. "2.5.2 proposed Understanding text https://w3c.github.io/Mobile-A11y-Extension/#swipe-trap" taken up [from Kim] 16:09:54 Kathy: did you have a chance to read – any comments or changes 16:11:11 Jon: most mobile screen technologies also allow Explore by touch – is this acceptable 16:11:58 Chris: no. swipe gestures would not be accessible to someone using a switch control 16:12:06 Jon: what would be acceptable for a developer to do 16:12:24 Chris: are you suggesting we need to put restrictions on what the alternative methods are? 16:13:31 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 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 Chris: right under 2.5.1 – is this even focusing on the AT being on? 16:15:03 Kathy: first part of it is when touch is modified by the platform – AT and touch 16:15:18 Jon: switch user is not using a swipe gesture, switch control is automatic 16:15:59 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 Jon: explore by touch – you go past and then you're stuck again 16:16:46 Kathy: recommended changes? To success criteria or add to understanding? 16:17:51 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 Jon: preserve users ability to not miss content 16:18:23 Chris: note, explore by touch is not an acceptable solution or something like that would clarify 16:18:50 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 Chris: could also related to the focus order trap under the traditional guidelines – 2.1.2 16:19:32 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 then miss content without knowing it was missed. This success criterion is similar to WCAG 2.1.2 No keyboard trap. 16:20:34 Jeanne: proposal for understanding 16:21:21 Jon: worried you can interpret the success criteria otherwise 16:21:51 Kathy: what if we took off the part about moving focus away 16:23:36 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 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 Jon: I think we were trying to say is with the AT on is possible to get into a trap 16:25:30 Jon: maybe it's swipe gestures that's the problem 16:25:39 Chris: it's not swipe gestures that's an issue it's just focusing anything in any way 16:25:46 Chris: you have to separated from the touch 16:26:10 Kathy: if we took out using swipe gestures 16:26:58 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 ...still relying on keyboard 16:27:34 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 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 Chris: take the word keyboard out of keyboard trap, call it navigation trap and how is the criterion different 16:29:18 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 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 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 Chris: that makes more sense to me 16:31:17 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 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 Chris: I'm not sure what that process you outlined was but I'd be happy to do it 16:33:30 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 Chris: completely generalize it – wording would become no navigation trap 16:34:28 Marc: generalizing 2.1.2 – I like the no navigation trap. I like the proposal Kathy did earlier 16:34:59 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 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 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 Jon: I think as we document our concerns if it gets rolled into 2.1.2 that's fine later 16:37:01 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 Jon: I can do the success criteria one – was consensus to leave swipe in or take it out 16:37:50 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 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 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 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 Jon: do we want to say no touch trap – do we want to keep Swype in the name 16:39:18 This success criterion is similar to WCAG 2.1.2 No keyboard trap. 16:39:29 "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 Action: Jon 2.5.2 SC 16:39:31 Created ACTION-41 - 2.5.2 sc [on Jonathan Avila - due 2016-03-10]. 16:40:20 Action: Chris document how this is different from 2.5.2 – add text after 16:40:20 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 Marc: just put suggestion in IRC about action 42 16:41:46 Henny: I completely agree – will add clarity referencing back 16:43:15 ... 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 Jon: I'm a little hung up on taking focus away part – touch gestures or navigation gestures 16:44:05 Kathy: can we put an example in 16:44:45 Kathy: we have to define linear navigation methods. If we added that into the success criteria rather than swipe gestures 16:44:59 ... 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 Kathy: that's a point for the understanding document to – key point is user needs to know where they are 16:46:11 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 ... 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 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 Chris: did you touch the top of the page of the bottom of the page – you're not sure 16:46:58 Kathy: because you don't know context 16:47:47 Kathy: clarify the example? 16:47:49 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 list of links). 16:48:56 Jon: would you prefer reading order or focus order – there could potentially be differences 16:49:04 Kathy: I think since were talking or navigation methods focus might make more sense 16:49:07 +1 for focus order 16:49:16 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 ... 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 +1 for focus order 16:49:38 +1 for focus order 16:50:06 +1 for focus order 16:50:11 +1 for chris' proposal 16:50:45 +1 Jon's proposal 16:50:50 Jon: I didn't say explore by touch, but I said it has to go to the next thing 16:50:55 +1 jon's proposal 16:51:08 Jon: bottom of page and you could navigate backup 16:51:26 Jeanne: I don't know of any user agent the doesn't wrap in the focus order 16:51:28 +1 for Jon's proposal 16:52:41 Kathy: if it's more of a user agent thing are we worried about wrap in focus order 16:53:13 Jon: wonder if we could put something like prior and next when applicable 16:53:23 Kathy: add to understanding, make sure success criteria isn't so complex 16:53:51 Kathy: can we change it so we don't have next in there – logical item in focus order? 16:54:01 Jon: past and next – past is maybe a little bit better 16:54:02 ... 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 other means of sequential navigation such as a keyboard or switch control. 16:56:01 ... 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 navigation such as a keyboard or switch control. 16:56:17 +1 16:56:19 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 Marc: does it really need to be based on assistive technology being on 16:59:28 Jon: I think it would be covered already under 2.1.2 16:59:34 Kathy: maybe we should add that to the understanding 17:00:02 Kathy: any other suggestions or changes? 17:00:10 +1 17:00:14 +1 all looks good 17:00:22 +1 to Chris & Jon's proposed cahnges 17:00:25 +1 to SC and understanding 17:00:27 +1 Chris and John's proposals 17:00:30 +1 to both the revised Understanding text and to the Success Criteria 17:00:37 +1 to Chris and Jon's proposal, nice work! 17:01:43 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 Resolution: revised Understanding text and to the Success Criteria 17:02:43 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 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 rrsagent, make minutes 17:03:51 I have made the request to generate http://www.w3.org/2016/03/03-mobile-a11y-minutes.html jeanne 17:04:19 rrsagent, make logs public 17:05:56 zakim, close action-41 17:05:56 I don't understand 'close action-41', jeanne 18:06:54 Present+ Kim, Henny, Chris, Marc, Jatin 18:07:08 Regrets+ David 18:07:28 rrsagent, make minutes 18:07:28 I have made the request to generate http://www.w3.org/2016/03/03-mobile-a11y-minutes.html Kim 18:11:27 rrsagent, bye 18:11:27 I see 2 open action items saved in http://www.w3.org/2016/03/03-mobile-a11y-actions.rdf : 18:11:27 ACTION: Jon 2.5.2 SC [1] 18:11:27 recorded in http://www.w3.org/2016/03/03-mobile-a11y-irc#T16-39-31 18:11:27 ACTION: Chris document how this is different from 2.5.2 – add text after [2] 18:11:27 recorded in http://www.w3.org/2016/03/03-mobile-a11y-irc#T16-40-20