Mobile Accessibility Task Force Teleconference -- 05 Nov 2015

<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> 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

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

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

- DRAFT -

Mobile Accessibility Task Force Teleconference

05 Nov 2015

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output