See also: IRC log
<trackbot> Date: 24 September 2015
<Alan_Smith> + alan
<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html
<Henny> Could you post the link again? I missed it earlier as wasn't logged in.
<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Accessibility_%28Guideline_2.5%29
<scribe> scribe: marcjohlic
Language was pulled in from keyboard to update 2.5.1
"2.5.1 Touch: All functionality of the content is operable through a touch interface without requiring specific timings for individual touch gestures, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)"
Kim: What can be done with touch that can't be done with keyboard
KW: Gregg added a comment on what might not be possible or practical under the updated 2.5.1
DF: What if more than one finger is involved - if you have multi-touch.
JS: It seems as though the path
exception is not the best way to go about this because we
always use the path exception for keyboard, but it does not
really apply to touch
... leaning more toward saying not everything needs to be
accessible by touch
... thing that are available by touch are also available when
VO is turned on
KW: Except we don't have anything under WCAG that applies to a specific AT
JS: Will try to go back and look
up the specific wording that was proposed - may have been
Jonathan or David that proposed
... You can't do custom touch objects or widgets that then
won't work with AT. Because standard HTML is supported - it's
more the custom widgets
... we have to say: "It has to work" when people are coding
things
DF: This would have cases where
some custom thing works with keyboard but may not work w/ touch
and AT enabled
... Many of these custom things are not keyboard
accessible.
KW: This would be the scenario
where keyboard works, but touch doesn't work when you have AT
enabled. We need to think about it in those terms as well. So
if something is keyboard accessible but not touch when AT is on
- woudl we want that to be a violation?
... There's a lot in custom gestures that become problematic.
Swipe that goes to pages as an example - work w/o AT, but stop
workign when AT is on
... Number of things like that that are getting built in that
work w/o AT and stop working when AT is enabled
<David> coming
KW: Any other suggestions on wording to convey this?
AS: Can we word that AT does not turn off that functionality?
KW: It's not that they would be turnign anything off, it's just that it doesn't work or have a mapping
http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html
<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Accessibility_%28Guideline_2.5%29
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Accessibility_(Guideline_2.5)
<David> I'm in
DM: There's a 2.5.4 Modified Touch When touch input behavior is modified by built-in assistive technology, all functionality of the content is still operable through touch gestures. (Level A)
<David> http://davidmacd.com/test/w3ctest.html
DM: There's 3 versions of 2.5.4 due to updates from comments
1) 2.5.4 Modified Touch: When touch input behavior is modified by built-in assistive technology, all functionality of the content is still operable through touch gestures. (Level A)
2) 2.5.4 Touch: For pages and applications that support touch, all functionality of the content is operable through touch gestures with and without system assistive technology activated. (Level A)
3) 2.5.4 Touch: For pages and applications that support touch, all functionality of the content is operable through touch gestures with and without system assistive technology activated, without relying on pass through gestures on the system (Level A)
4) SC 2.5.4: On devices that support touch input, all functions are available vie touch or button presses also after AT is turned on (i.e. without the use of external keyboards).
DM: The last version was getting
closer
... Some of the default gestures change when VO is on.. maybe 7
or 8. We have to manage these.
... If a developer messes with these then we're in trouble -
for example the swipe+down
KW: My problem w/ relying on passthrough gesture is that it is here and now and it may change
DM: True, but it's something that
we rely on for JAWS and has been pretty stable, but I hear what
you're saying: "for a success criteria do we want to be that
granular"
... Maybe having a failure for passthrough gestures
... Maybe we write a draft of 2.5.4 and include a note that
we're still investigating passthrough gestures and defaults
<Detlev> Is that online somewhere, David?
DM: Working on a matrix - only 10 gestures long at the moment
KW: Developer doc has the gestures specific to VO
AS: Android has AT specific gestures as well
<Detlev> Applevis discussion of some VO pass through gestures (mainly four / five finger swipe) http://www.applevis.com/forum/ios-ios-app-discussion/voiceover-four-and-five-finger-gestures-ios-7-and-ios-8-ipad
"Responding to Special VO Gestures" in the Apple documentation
<Kathy> What about this: All functionality of the content is operable through touch gestures with and without system assistive technology activated
KW: What if we simplified it
DM: That's an earlier version
KW: Trying to get it less
wordy
... "All functionality of the content is operable through touch
gestures with and without system assistive technology "
DM: I think it's a good direction
AS: Sounds good to me too
KW: From there we can bring in techniques and failures to cover the other scenarios
+1
DM: Does "functionality" include
flat text?
... You should be able to get to it via touch
KW: Wouldn't that be a SC on readability?
DM: Yes, but i think you want to
be able to get to it via touch
... "all functionality and content is operable .."
KW: But i'm not sure we should
say "content" - we're talking about the functions
... just like there is reading mode in JAWS and other AT
... don't want them to think they have to do something to get
content read.
... an example was a site that had put aria-live on everything
because they thought they had to do something to get a screen
reader to read it
<Kathy> All functionality is operable through touch gestures with and without system assistive technology
DF: Are we back to the situation
where we demand that everything is available by touch full
stop?
... the simplified version doesn't qualify that
DM: True the qualification that we talked about yesterday, we lost that
KW: We're not saying all functionality is available with touch - just that all touch functionality is available with AT
<Kathy> All functionality that is operable through touch gestures, is also available with touch with system assistive technology
DF: Are there exceptions for things like text input that we talked about - maybe we address those with a note or something
<Detlev> OK fair enough
DM: WCAG draws a line where if something dis-proportionally affects PwD
KW: We need to wordsmith this one
a bit more - we'll pick this one up next week. Give it some
thought or send some suggestions around
... getting closer - just need to keep plugging away at
this
... Let me know if you've finished any techniques so that we
can get those surveyed
trackbot, end meeting
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/and example/an example/ Found Scribe: marcjohlic Inferring ScribeNick: marcjohlic Default Present: Kathy, alan, Henny, jeanne, marcjohlic Present: Kathy alan Henny jeanne marcjohlic Found Date: 24 Sep 2015 Guessing minutes URL: http://www.w3.org/2015/09/24-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]