See also: IRC log
<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
<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
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]