See also: IRC log
<Kathy> trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force Teleconference
<trackbot> Date: 07 July 2016
Kathy: We are going to briefly
discuss what we can change, then end call early
... we can't change the SC, but we can change the definition or
the understanding
... start thinking about two-stage approach. Can we change
definition under 2.1 now without changing the success criteria
language, or do we need something patched in now and go down
that direction for 3.0
... that's what we need to look at overall for 2.1 and 3.0
Patrick: interchange with Greg and link – my whole point initially was a wanted to get this discussed within our task force first so we can iron out some of these things before. Uphill struggle to get folks to understand
Kathy: we might want to just bring this overall to the working group regardless but I think we should have several different options. I posed the question – they said we could change the definition but the success criteria couldn't change until 3.0
Patrick: that's a very limiting
approach particularly because the change I propose doesn't go
against what it currently says – not that things that were not
accessible in 2.0 will now become accessible but rather the
opposite that certain approaches that were valid under 2.0 but
don't work for touch – so making it harder to satisfy amended
criteria. But I get the point that if we are...
... taking...
... the current language as being immutable we could probably
look at redefining what keyboard interface actually means
though it will in my view make it look more awkward,
particularly in the light of WCAG already being criticized for
using obscure language. It can be done we can say keyboard
interface actually includes. It just adds a layer of
indirection which may not be completely...
... obvious. We can add to understanding to stress that point.
On the very first reading it will always still look like why is
touch with AT a keyboard interface
Kathy: I think overall we need to
bring this to the working group. So we'll have a discussion in
the task force and probably that will happen next week, because
not very many people on the call right now. If you can look at
the definition and see if you can change the definition by
keeping the success criteria language the way it is and see if
we could go in – timeline is so short we...
... have to have all this wrapped up we can't spend too much
time going back and forth. If we have multiple options for the
working group and we can get them to tell us what we can and
can't do and just move forward and get things defined within
the limits their setting for us…
Patrick: I agree with that. I
will take a look at last comments and see if there's a way I
can salvage the work that I put in this – change definition
etc. the main point that needs to be addressed is basically
touch +AT. It uses gestures but it's the ATthat interprets
them.Then we can move onto as an author if you do your own
gesture detection, how to make sure that still works
for...
... users that are using touch interface but might have
mobility issues, not necessarily touch +AT but broad touch
itself. And then the advanced touch which is using stylus that
also has tilt and rotation and everything else – the fancy
touch that we talked about..
... once we've sorted the touch plus AT scenario we can move on
other input modalities that arise from having touch and
stylus…
Kathy: encourage everyone to read through the thread. We'll discuss next week
David: the idea of expanding it
doesn't bother me. My only concern is it seems to me that it
can be construed that the keyboard requirements are less that
so another words every test that I do over the last eight years
but still have to be done, and that would still fail people on
keyboard accessibility. I love the idea of unifying and
expanding, as long as we don't lose what we've had in...
... terms of functional understanding of keyboard
accessibility
Patrick: everything that
previously failed would still fail. But not everything that
passed previously would still pass. Things such as if you used
keyboard specific input handlers such as onkeypress or
onkeydown, it would pass under 2.0 it would not pass in the
stricter definition – so it is actually a strengthening in my
eyes of this particular requirement. Maybe too much the
opposite...
... way perhaps.
David: I know this is a problem with iOS but technically mobile will not pass if it can be keyboard operated. I guess as long as we're not losing that in the wording reflects that. User who may be able to help us, lawyer who went blind, government regulation. Language that isn't too broad or too narrow
Patrick: duplicate a lot of
language – compromise, though. 3.0 unify the idea
... option one, option two let's tweak it slightly, option
three let's duplicate it, but that's not our preferred
position. We can send and say this will be our preferred, least
preferred but we can live with and see how it goes
... I think we can get somewhere with this – an agreement that
the thinking behind it is fine now it's just finding the right
form for everyone. I think we can get somewhere anyway. I'll
keep working on that this week. May have additional thoughts
and ideas by the next call, will put in the wiki
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim WARNING: No "Topic:" lines found. Present: DavidMacDonald Kim Kathy Chris Patrick Regrets: Shadi Alan Mark Henny Jeanne Found Date: 07 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/07-mobile-a11y-minutes.html People with action items: 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]