See also: IRC log
Kathy: any questions on assignments or information for the group
Marc: time opening up in the next few weeks
Chris: asking about failure template
Kathy: default template – also in the wiki, also look at some of the other failures
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Failure_of_2.5.3
Kathy: here's an example – you can use this general format
Jeanne: that's a really good example of a completed one
Kathy: any other questions comments on assignments
Kathy: did you have a chance to read – any comments or changes
Jon: most mobile screen technologies also allow Explore by touch – is this acceptable
Chris: no. swipe gestures would not be accessible to someone using a switch control
Jon: what would be acceptable for a developer to do
Chris: are you suggesting we need to put restrictions on what the alternative methods are?
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
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
Chris: right under 2.5.1 – is this even focusing on the AT being on?
Kathy: first part of it is when touch is modified by the platform – AT and touch
Jon: switch user is not using a swipe gesture, switch control is automatic
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
Jon: explore by touch – you go past and then you're stuck again
Kathy: recommended changes? To success criteria or add to understanding?
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.
... preserve users ability to not miss content
Chris: note, explore by touch is not an acceptable solution or something like that would clarify
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
Chris: could also related to the focus order trap under the traditional guidelines – 2.1.2
<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
<jeanne> then miss content without knowing it was missed. This success criterion is similar to WCAG 2.1.2 No keyboard trap.
Jeanne: proposal for understanding
Jon: worried you can interpret the success criteria otherwise
Kathy: what if we took off the part about moving focus away
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
... 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
Jon: I think we were trying to
say is with the AT on is possible to get into a trap
... maybe it's swipe gestures that's the problem
Chris: it's not swipe gestures
that's an issue it's just focusing anything in any way
... you have to separated from the touch
Kathy: if we took out using swipe gestures
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...
... still relying on keyboard
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
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
... take the word keyboard out of keyboard trap, call it
navigation trap and how is the criterion different
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
Kathy: do we have a failure under
the keyboard trap? Keyboard is keyboard interface it doesn't
mean the actual physical keyboard
... 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
Chris: that makes more sense to me
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
Jeanne: I would recommend someone write this up as a persuasive argument that we need a WCAG 2.1 rather than an extension
Chris: I'm not sure what that
process you outlined was but I'd be happy to do it
... it's not that there aren't mobile considerations, it's just
that the mobile considerations can be expanded on what's
already there
... completely generalize it – wording would become no
navigation trap
Marc: generalizing 2.1.2 – I like the no navigation trap. I like the proposal Kathy did earlier
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
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
... 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
Jon: I think as we document our concerns if it gets rolled into 2.1.2 that's fine later
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
Jon: I can do the success criteria one – was consensus to leave swipe in or take it out
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
<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.
<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.
<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.
Jon: do we want to say no touch trap – do we want to keep Swype in the name
<Kathy> This success criterion is similar to WCAG 2.1.2 No keyboard trap.
<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, ... "
<scribe> ACTION: Jon 2.5.2 SC [recorded in http://www.w3.org/2016/03/03-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-41 - 2.5.2 sc [on Jonathan Avila - due 2016-03-10].
<scribe> ACTION: Chris document how this is different from 2.5.2 – add text after [recorded in http://www.w3.org/2016/03/03-mobile-a11y-minutes.html#action02]
<trackbot> Created ACTION-42 - Document how this is different from 2.5.2 – add text after [on Chris McMeeking - due 2016-03-10].
Marc: just put suggestion in IRC about action 42
Henny: I completely agree – will add clarity referencing back
<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.
Jon: I'm a little hung up on taking focus away part – touch gestures or navigation gestures
Kathy: can we put an example
in
... we have to define linear navigation methods. If we added
that into the success criteria rather than swipe gestures
<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.
Kathy: that's a point for the
understanding document to – key point is user needs to know
where they are
... 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
<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.
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
Chris: did you touch the top of the page of the bottom of the page – you're not sure
Kathy: because you don't know
context
... clarify the example?
<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
<jeanne> list of links).
Jon: would you prefer reading order or focus order – there could potentially be differences
Kathy: I think since were talking or navigation methods focus might make more sense
<jeanne> +1 for focus order
<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.
<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.
+1 for focus order
<chriscm> +1 for focus order
<Henny> +1 for focus order
<jeanne> +1 for chris' proposal
<jeanne> +1 Jon's proposal
Jon: I didn't say explore by touch, but I said it has to go to the next thing
<chriscm> +1 jon's proposal
Jon: bottom of page and you could navigate backup
Jeanne: I don't know of any user agent the doesn't wrap in the focus order
<Henny> +1 for Jon's proposal
Kathy: if it's more of a user agent thing are we worried about wrap in focus order
Jon: wonder if we could put something like prior and next when applicable
Kathy: add to understanding, make
sure success criteria isn't so complex
... can we change it so we don't have next in there – logical
item in focus order?
Jon: past and next – past is maybe a little bit better
<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
<chriscm> other means of sequential navigation such as a keyboard or switch control.
<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
<chriscm> navigation such as a keyboard or switch control.
<marcjohlic> +1
<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.
Marc: does it really need to be based on assistive technology being on
Jon: I think it would be covered already under 2.1.2
Kathy: maybe we should add that
to the understanding
... any other suggestions or changes?
<jeanne> +1
<chriscm> +1 all looks good
<Kathy> +1 to Chris & Jon's proposed cahnges
<jon_avila> +1 to SC and understanding
+1 Chris and John's proposals
<marcjohlic> +1 to both the revised Understanding text and to the Success Criteria
<Henny> +1 to Chris and Jon's proposal, nice work!
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
RESOLUTION: revised Understanding text and to
the Success Criteria of 2.5.2 No Swipe Trap to No Touch
Trap
... 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
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) Succeeded: 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/ No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Present: jeanne Kathy jon_avila Kim Henny Chris Marc Jatin Regrets: Alistair Alan David Found Date: 03 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/03-mobile-a11y-minutes.html People with action items: chris jon[End of scribe.perl diagnostic output]