- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 03 Mar 2016 13:10:45 -0500
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <56D87E25.3010000@redstartsystems.com>
*MATF Minutes 3 March 2016 link: *
https://www.w3.org/2016/03/03-mobile-a11y-minutes.html
*Text of minutes:*
Mobile Accessibility Task Force Teleconference
03 Mar 2016
See also: IRC log <http://www.w3.org/2016/03/03-mobile-a11y-irc>
Attendees
Present
jeanne, Kathy, jon_avila, Kim, Henny, Chris, Marc, Jatin
Regrets
Alistair, Alan, David
Chair
Kathleen_Wahlbin
Scribe
Kim
Contents
* Topics <https://www.w3.org/2016/03/03-mobile-a11y-minutes.html#agenda>
1. Review assignments
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
<https://www.w3.org/2016/03/03-mobile-a11y-minutes.html#item01>
2. 2.5.2 proposed Understanding text
https://w3c.github.io/Mobile-A11y-Extension/#swipe-trap
<https://www.w3.org/2016/03/03-mobile-a11y-minutes.html#item02>
* Summary of Action Items
<https://www.w3.org/2016/03/03-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2016/03/03-mobile-a11y-minutes.html#ResolutionSummary>
------------------------------------------------------------------------
Review assignments
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
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
<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
2.5.2 proposed Understanding text
https://w3c.github.io/Mobile-A11y-Extension/#swipe-trap
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
Summary of Action Items
*[NEW]* *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]
*[NEW]* *ACTION:* Jon 2.5.2 SC [recorded in
http://www.w3.org/2016/03/03-mobile-a11y-minutes.html#action01]
Summary of Resolutions
1. revised Understanding text and to the Success Criteria of 2.5.2 No
Swipe Trap to No Touch Trap
<https://www.w3.org/2016/03/03-mobile-a11y-minutes.html#resolution01>
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/03/03 18:07:33 $
--
___________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>
www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly
Blog: Patch on Speech
+Kim Patch
@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 3 March 2016 18:11:29 UTC