See also: IRC log
<trackbot> Date: 05 November 2015
<David> tried password xxxxxxxx but didn't work
<David> s/maft/xxxxxx
<Kathy> http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation
<Kathy> https://www.w3.org/2002/09/wbs/66524/10-21-2015-Survey/results
<Kathy> https://www.w3.org/2002/09/wbs/66524/10-21-2015-Survey/results
<Kathy> http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation
<scribe> scribe: marcjohlic
KW: Alistair suggested: "I'd
change "system assistive technology" to "a system assistive
technology requiring touch"..."
... Believe he was getting at that it's AT that supports
touch
... What are things in AT that modifies touch
DM: VoiceOver has it's own gestures - overrides even if an app has the same gestures mapped
JR: Some switch systems override and turn entire screen into one button
DM: Trying switch now - it's just moving through item by item - similar to a swipe
JR: Right and you can have it set to just be a simple touch - but you could also have it setup to go into a whole array of functions
KW: So if something is not touch accessible, it would not work with the switch on either
JR: Right
DM: I think this doc could be sent to the WCAG group. I think we're pretty close
JR: I like David's remapping
<Kathy> 2.5.1 Touch: All functions available by touch (or button presses) are still available by touch (or button presses) after system assistive technology that remaps touch gestures is turned on. (Level A)
KW: Have it as a Level A -
whether or not we end up with levels is a separate
discussion
... I think there is a clear priority of things that should
happen
DM: I think it's worth putting a mapping on it - whether it's dropped later on or not - it will help for now
JR: I agree
... What does the "or button presses" mean ?
DM: It was suggested that many of hte gestures could be done w/ button presses
JR: Physical or on screen?
DM: Physical
KW: Can we get rid of button pressess - and leave that as part of the explanation?
DM: OK with dropping it - I think someone mentioned somethign about it - they were talking about physical buttons liek on the side of the phone.
<Kathy> 2.5.1 Touch: All functions available by touch are still available by touch after system assistive technology that remaps touch gestures is turned on. (Level A)
DM: OK with dropping - but maybe add a comment mentioning the physical button presses
JR: Looks good
DM: Makes sense
+1
KW: Any other techniques we need
to add here - just to note it
... Or Failures?
... Currently we just have M003 Touch Activation: Activating
elements via the touchend event
JR: Touchend is a different issue - isn't the point there to cover when something it touched accidentally?
KW: yes, you're right - so where would it fall under?
JR: I think it has something to
do with error minimization under 3.x.x
... It could also be its own thing in Touch and Pointer
KW: Can take M003 out for now -
and move it to unknown placement techniques
... A technique around: "Using standard one touch controls"
DM: First Failure would be "Infinite scrolling still works when screen reader is turned on"
<Kathy> Infinite scroll gesture is not available with screen reader
+1
DM: "with system screen reader"
<Kathy> - Techniques ○ Using standard one touch controls ○ Providing touch access for custom controls - Failures ○ Infinite scroll gesture is not available with system screen reader
<David> Unlabeled or badly labeled images. (very annoying if one is reading an article and such graphics are in the middle)
<David> · Improperly organized webpages. (higherarcical information organization is key to successful navigation of a webpage with a screen reader for so many reasons)
<David> · Inaccessible video content. (so many times, I encounter an article or something with embedded multimedia content that I either can’t access with jaws [unlabeled buttons] or don’t know is there at all.)
<David> · Websites that load audio content automatically. (very hard to stop with a screen reader if its loud enough)
<David> · Improperly labeled links. (click here, whaaat?)
<Kathy> 2.5.2 No Swipe Trap: When touch input behavior is modified by built-in 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 using swipe gestures or the user is advised of the method for moving focus away.
KW: Find this one to be too long - get lost in it
DM: Detlev put this one out there - basically if you can get into something with your keyboard you can get back out of it with your keyboard
<David> Unlabeled buttons and controls
<David> 2.
<David> Faking modal windows with non-modal CSS
<David> 3.
<David> Elements onscreen but not in swipe order
<David> 4.
<David> Nonstandard controls when a standard one exists
<David> 5.
<David> Updating that causes voiceover to keep refreshing that
JR: These are good - but doesnt' really speak to someone getting stuck in something
<David> http://www.sitepoint.com/mobile-accessibility-fails-need-wcag3/
DM: Mentions keyboard focus traps
KW: Talking about things that don't automatically close
DM: Good one - but not a trap
KW: Problem is that you can't see the content under it afterward - so it's a block
DM: Definitely a failure we should capture
KW: She also has the mobile hover traps
JR: She uses this term of reverse trap which is interesting
<David> Component can be opened but cannot be closed with touch when a system screen reader is running
DM: This could be Failure
<David> Component can be opened but cannot be closed with a keyboard when a system screen reader is running
KW: Would be put this under 2.1.1?
DM: No, under 2.5.1
<David> Component can be opened but cannot be closed with a keyboard
DM: This would be a failure for 2.1.1
KW: Title attribute Gian raises
is more of a user agent issue
... Next week would like to see if we can get through rest of
Touch proposal - so that we can get it to the WCAG WG. In the
survey fill out that section #2. Review Alistair's
comments.
... I'll make the changes in GitHub - failures, techniques, and
language changes.
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) FAILED: s/maft/xxxxxx/ Succeeded: s/matf/xxxxxxxx/ Found Scribe: marcjohlic Inferring ScribeNick: marcjohlic WARNING: No "Topic:" lines found. Default Present: marcjohlic, Kathy, David, Jan Present: marcjohlic Kathy David Jan Found Date: 05 Nov 2015 Guessing minutes URL: http://www.w3.org/2015/11/05-mobile-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]