W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

15 Oct 2015

See also: IRC log

Attendees

Present
Kathy, marcjohlic
Regrets
Chair
Kathy Wahlbin
Scribe
marcjohlic

Contents


<trackbot> Date: 15 October 2015

<Kathy> + Kathy

<Kathy> http://kwahlbin.github.io/Mobile-A11y-Extension/

<Kathy> http://kwahlbin.github.io/Mobile-A11y-Extension/

<scribe> scribe: marcjohlic

<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html

Continuation of the Discussion of Touch Proposal

<David> lost audio will come back

KW: Discussing whether or not we can save this once AT is turned out - all functionality still available with AT on.

<David> back

KW: Also talked about all functions vs taking some language from Keyboard success criteria where there are some exclusions

DF: Possibly an equivelence when a gesture doesn't work w/ AT, but user can still access alternate menu that brings the same functions

<jon_avila> iOS native apps solve this through the actions rotor which is automatically set to the actions rotor option for example in native email app

KW: Agree - but extends beyond that - for example device manipulation - for example user has to shake the device. Will need alternates to do that - so that functions are still available. We should define what that means.

<jon_avila> But this would be an issue for web apps which don't have a way to exposing actions

DM: At the end of last session we id'd 4.1.2 as a precedent in this area
... Also talked about reporting to the API - can we require that it reports to the API rather than it works with AT
... Jan suggest we may need to limit to screen reader, however we know what of the criticism of WCAG is it's focus on screen readers
... Any tool that lets you look at the API similar to Inspect for iOS?

JA: iOS has the Accessibility Inspector - but it is limited to things like label, hint, trait etc
... There are some automated tools

DM: If there's not an app that will let you see as you go through everything it sounds like it would be a difficult thing to test.
... Is the requirement that we have in the language - that all functions available by touch and button presses is still available by touch and button presses once AT is turned on - is that too wide?

DF: Are there any ATs for mobile that are not system technologies?

DM: All kinds of possibilities. For example Windows mobile MAY wind up w/ a version of JAWS at some point
... What we are seeing is that most of the basic AT is built right into the OS

AS: : Another challenge is that we may say touch is still available when touch is on, but someone with a switch may want focus still on - not as concerned with touch.

DM: Probably covered by other WCAG checkpoints at a base level - and with talk currently that will need to meet AA to get into the extensions

KW: Our current statement may fall apart for switch users
... Heard it said that it doesn't work if touch is available because switch works differently

JA: I think we're saying that in addition to programmatically working we're saying that it has to work with system AT on.

DM: Some people may ask "what is system assistive technology" - so we will have to define that.

DF: What is the reasoning why something like scalable font is not considered system AT? Zoom is - but scalable font is not - where do you draw the line?

DM: We don't have a good line right now - think that's an area where we need to explore that definition.

JA: For this particular case, large print isn't an issue because it's not an interactive thing. That's why we almost need a different definition for this one.
... Even if we agree on it - others will push back

Jan's reference from last week for adding gestures: Hammer.js http://hammerjs.github.io/

JA: Concern is that folks will come up with all sorts of keyboard alternatives

DM: We could try to come up with a Failure, but where would we map it to? Seems to me that we need to go with a Success Criteria

KW: Kind of at a roadblock with this - maybe it needs more exploration. The touch access on website for touch end - isn't that a problem also? Are there other things on the web where this would applicable. Touch end comes to mind

AS: In the past WCAG guidelines were not necessarily specific, but now we're trying to come up w/ device specific (mobile).

DM: One issue we could plug quickly is that right now if you have a responsive design and you have a desktop view and a mobile view - the desktop view can server as the conforming view. Often devs will get desktop correct, but the mobile version is a disaster.

KW: And I've had a client w/ the exact opposite

DM: I think that's another success criteria that I haven't put in yet, but I think for this mobile extension we should get rid of that conforming desktop piece.
... We want things to work when AT is turned on - I don't know of any other breaks outside of screen reader - there may be. But is the big question now around using the term "system AT"?

JA: Have we discussed this w/ WCAG wg?

KW: Not yet, but we can start bringing things to them - try to get some wider feedback
... We should start collecting other scenarios - we've been focused on this one - but if we think about other scenarios that would be affected we may see another way around this
... Will add that to the survey - we may be able to get some more feedback

DF: May be other ARIA constructs that were conceived before mobile was considered

KW: We need to be careful about posting "hey here's a new success criteria" - we don't have the extension model finalized in WCAG - but we can start getting some feedback

JA: I was looking for the term "assistive technology" in WCAG. There is some precedent in 4.1.2 - so maybe if we could say somehting about programmatically or available to assistive technologies. I think what we really want to say is that it doesn't require a physical keyboard.

KW: One thing I'm hearing that is different is that we're saying it needs to be operable w/ AT - and what you're saying is that it's programmatically available.
... That might be a little nuance that we want to explore further

DM: What if we just say ".. with a screen reader on"

KW: But we have to see if there are other issues outside of screen reader. Also we've been focused on touch, but what if other methods of operation come around
... We may get push back because there are other modes of interaction

DM: Certainly voice

KW: Trying to think of all of the different things that go into this - what's coming - where is it going - we'll be constantly inventing interaction models.
... Next steps:
... No meeting next week
... Will send out a survey on the touch proposal to gather more feedback
... Survey will also be going through extension document - see what's missing - getting some feedback
... Take a look at these things over the next two weeks and we'll see what are the outstanding questions we have so that we can get this outline going

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/15 15:58:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: marcjohlic
Inferring ScribeNick: marcjohlic
Default Present: Kathy, marcjohlic
Present: Kathy marcjohlic

WARNING: Fewer than 3 people found for Present list!

Found Date: 15 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/15-mobile-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]