- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 28 Jul 2016 12:11:02 -0400
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <579A2E96.8070504@redstartsystems.com>
*MATF Minutes 28 July 2016 link:
*https://www.w3.org/2016/07/28-mobile-a11y-minutes.html
*
Text of minutes:*
Mobile Accessibility Task Force Teleconference
28 Jul 2016
See also: IRC log <http://www.w3.org/2016/07/28-mobile-a11y-irc>
Attendees
Present
Kathy, patrick_h_lauke, jon_avila, DavidMacDonald, jeanne, Alan,
kim, Henny, Chris, Detlev
Regrets
Alistair
Chair
Kathy
Scribe
Kim
Contents
* Topics <https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#agenda>
1. Patrick's pull requests
<https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#item01>
2. Patrick's Comments on the note
<https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#item02>
3. Touch and other input methods proposal (Patrick, Detlev &
Chris)
<https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#item03>
4. look at all the success criteria that we had suggested for
mobile and identify any other gaps that were missing or other
concerns that you may have, then we can get those scheduled to
talk about
<https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#item04>
* Summary of Action Items
<https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2016/07/28-mobile-a11y-minutes.html#ResolutionSummary>
------------------------------------------------------------------------
trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force Teleconference
<trackbot> Date: 28 July 2016
Patrick's pull requests
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-Extension/pull/9
Patrick: we did talk about that on the last call -- I think generally
the feeling was that it was mostly hitting the right notes. Will add
David's suggestion
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-TF-Note/pull/37
Patrick's Comments on the note
<patrick_h_lauke> https://github.com/w3c/Mobile-A11y-TF-Note/pull/37/files
Patrick: talks about HTML 5 form fields -- just about the correct type
of input that the user agent will switch to the appropriate keyboard.
Input method editor API is generally more about complex scenarios for
IME where you have Japanese where you need to tweak the keyboard
Kathy: I'm fine with those changes -- anybody have objections?
<davidmacdonald> fine w me
<Alan_Smith> Alan +1
no objections
<Detlev> +1
Touch and other input methods proposal (Patrick, Detlev & Chris)
Kathy: on the agenda today we have to go over the recommendations on
touch and other input methods -- Patrick's githhub link.
<patrick_h_lauke>
https://gist.github.com/patrickhlauke/96110b10547770021e58f5098dd31087
Patrick: go to that link -- this is all very rough. Conversation with
Detlev, who summarized into list of SCs. I fleshed out some of them.
This is diametrically opposite from my previous approach of generalizing
2.1. This approach is put down all sorts of input methods scenarios and
see what we need to do with them
<davidmacdonald> cursory reading
Patrick: we talk a lot about keyboards. There are specific things for
keyboard with AT. We talked about touch. Similar keyboard scenario --
jaws lead to certain situations where if an author has -- still
satisfying 2.1.1 and 2.1.3 and author has added custom events for any
arbitrary keys on the keyboard, they pass 2.1.1 but as soon as assistive
tech is running on top of the regular browser...
... and you've got a physical keyboard situation where you're not able
to hit particular keys because the AT will swallow those keystrokes
... AT and speech like we talked about last week we generally fall under
this
... when it's touch with assistive tech or speech with assistive tech --
high level of events move the focus to this particular element -- this
helps disambiguate some of the discussion that we always have with some
of the things about gestures and swipes and differentiating whether
author has to do something about it or AT interprets
... this tries to separate that out in a sensible way.
Detlev: author requirement -- say web app that has keyboard shortcuts,
to author to make sure there's always another way, say a menu or
on-screen that will do the same thing as the keyboard shortcut. Would
that be a requirement -- I'm not sure which would take precedent the AT
or the authors keyboard shortcut
Patrick: under 2.6.1 requirements and techniques -- you have to have
some other form of control. You can have keypress handlers but you have
an alternative. You're not relying on the fact that a user can press an
arbitrary key at any point they want. This also plays into touchscreen
where the user can't always trigger the on-screen keyboard and therefore
can't always trigger arbitrary keys
... there's probably a little bit of overlap in certain area but
obviously satisfying all of these will make sure it's input agnostic or
have all the things that work for all the different scenarios of input
... the short answer is have a button that can be focused. The point of
a shortcut is that they are shortcut -- you can still use those if you
provide a menu it might take two or three steps to get to that
functionality but as long as the end result is that the user can still
actually get to it even if they cannot trigger arbitrary keystrokes
that's the idea
... a lot of the wording is not in a final SC stage -- this was just to
give some initial direction of these other sorts of things where we're
thinking about covering. Some may get tweaked or merged, touch with AT
we've already written that out, might need tweaking
... 2.7 advanced input that covers what we talked about -- we called
fancy pointers which is a stylus that recognizes tilt and twist, or a
pressure sensitive touchscreen
... also when you have additional sensors on the device 2.72 --
similarly feel free to take advantage of extra information such as
twist, light sensor information or rotation of a device, however users
may not have that sensor or have the sensor but not be able to use it at
all or accurately enough therefore make sure that functionality is also
available in a fashion that does not use...
... these sensors. Particularly with force touch that gels with Apple
advice in guidelines -- force touch is shortcut
... there will be exceptions but we want to say that if the primary
purpose of your app is to do this -- something like a game that you
explicitly want to make only tilt control or something like that or
brushstroke emulator -- that may be an exception
... however if that is not the core intent of the app you have to abide
by this SC
... need wordsmithing and gathering use cases, good examples of where
this applies and what we actually mean by this. Rough brain dump at the
moment
Kathy: there are areas where it's already written and finalized. Was
there anything that you merged or did you take what we had there and
reorganize it and add to that
Patrick: I don't think we dropped anything. We just added bits around it
and cobbled it together in some areas
<davidmacdonald>
http://www.davidmacd.com/blog/should-WCAG-require-all-functionality-by-mouse.html
David: I think it's the approach that we need to make in terms of
stepping back and being very granular and getting things past piece by
piece. I think there's a lot of review and maybe that's useful to bring
us all on the same page. Important to understand what the previous
people have been doing. The one new thing is 2.5.1 -- previously was
assistive technology thing. What were introducing...
... here is the pointer accessibility. I've been asking shouldn't we be
requiring all functionality by mouse. Pretty big requirement that we
haven't had previously. This is a big new introduction of something.
... most usability people are creating things to be usable by mouse
these days but we kind of left that out of WCAG. is it in our
jurisdiction to bring this forward or just go to the larger group?
Kathy: we've been looking at touch and pointer it's fine to do here. We
are talking touch and pointer
Patrick: were talking mouse, touch, stylist -- anything that falls under
the choose an X and Y point on the screen
... it's a big one -- it's one of those elephant in the room issues.
especially if we start looking at all these other types of inputs and
modalities it would be a strange omission not to have that there. If it
is as many say implied, then it should not be a problem the past that SC.
David: I'm intrigued whether we should or not. My concern around the
whole requiring pointer is this is the kind of thing that could take up
quite a bit of our bandwidth if we pursue it to try to get to an SC
stage with it. I'm wondering whether we want to put it as a priority
after we get the other ones that we feel really are causing trouble.
... I haven't found any user that's asked me about this. I'm wondering
if anyone else has found this as an accessibility issue or if it's just
a matter of completeness
Kathy: I think there are new devices out there that are tapping onto the
pointer technology now
Jeanne: I think this is about making ourselves technology neutral,
making us more forward compatible -- trying to instead of having 2.1
just the oriented toward past problems and past technology we're really
making the orientation more future proof
Kathy: as far as what we have to have done for December were proposing
the success criteria -- will going to take a look at all of those and
flesh out -- December deadline just success criteria and understanding
... there's a lot to get to that point but lot of these like touch
target size are almost finished. We could put this down and get to some
of the other ones first especially the ones that are almost done
David: I think the next step is now to start to create the success
criteria and plug in what we have already. AT remapping is pretty close
to being done. 2.5.1 keep it as it is now until the other ones are done
Kathy: keep in mind that the numbering means nothing
Patrick: my main concern was making sure that we cover all the bases --
speech input as well under the inputs with assistive tech. And we can
see are we missing anything -- are there gaps that we haven't even
considered?
<davidmacdonald> +1
Patrick: situations on-screen keyboard or if you're using speech and
saying press a press b -- I think the end result of that is it emulates
a keyboard and key events so those kinds of things relating to that
would generally fall onto the keyboard type of requirements. It's about
divorcing what the user is really doing and what is the end result that
the app sees. Does the app think it's a...
... keyboard event regardless of whether it's a keyboard or on-screen
keyboard
... purely the ones that using the accessibility API actually
programmatically move the focus in the UA to a particular element
without say faking 20 tabs strokes or something like that.. The ones
that actually activate something
Alan: with wearable devices -- we may have others things, proximity --
wearable devices may present new avenues of user input also
Patrick: it would depend on what it looks like to the app
... proximity might translate into a touch. If we had indie UI and it
was developed further that would be great, but I haven't seen any
indication. Could also fall under device inputs. We need to make sure
that were released open ended for the possibility of the types of events
<jon_avila> not at the moment
<Alan_Smith> "that we are at least open ended"
yes - scribe speako
<marcjohlic> So a +1 from me :)
David: next step look at comments
Kathy: does it make sense to continue on this document or incorporate it
in a pull request -- what's gonna be helpful for you?
Patrick: purely for myself I find it easier to look at this because this
covers just the input type stuff so it makes it -- zoom on my browser a
bit so I get a better overview. It's a little bit lost on the bigger
document. Personally I find it easier at this stage -- but it doesn't
make a huge bit of difference. Maybe take another two weeks to flesh it
out, then drop it in.
Kathy: we want to Inc. in before the end of the month for sure. We do
need to go through the rest of the comments. So would be good to look at
one document one we are going through the comments.
... need to incorporate only in one area when we do that
David: does it make sense to collapse everything we are not working on,
that's outside our scope
<davidmacdonald>
http://davidmacd.com/blog/an-accessible-expand-collapse-mechanism.html
Jeanne: I'm pretty flexible, I have to adjust my way of working to
pulling the branch and putting in the requests. I can accept pull
requests -- when they are ready
<patrick_h_lauke> https://w3c.github.io/Mobile-A11y-Extension/
Patrick: it's already quite cut down a for looking at this
... once I go through this and respect properly so it also generates the
table of contents that will help -- document outline on the left-hand side
Kathy: Jeanne does that make sense if he puts it in respec
<patrick_h_lauke> respec is a dark art...
<patrick_h_lauke> dark and annoying
Jeanne: have to figure that out
Kathy: any other comments
<davidmacdonald> +1
<Detlev> +1
Kathy: great work -- thanks for going through that. Next week we'll go
back through those, work in parallel with the other ones
look at all the success criteria that we had suggested for mobile
and identify any other gaps that were missing or other concerns
that you may have, then we can get those scheduled to talk about
David: everything that I was concerned about with mobile is in there now
Kim: longer discussion about speech at some point, some issues are
queued up here:
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Speech_Input_Accessibility_(Guideline_2.7)
<https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Speech_Input_Accessibility_%28Guideline_2.7%29>
pay no attention to the number -- feel free to add to this document
Chris: switch access -- I don't know if we have time to talk about that now
Kathy: we can put that as an item to talk about
... anything else
... if you do think of anything else let me know and will start getting
a consensus together. I'm going to put together a rough timeline with
Kim to go over-- the beginning of December is going to come quickly. If
you do have any other topics of things we need to cover let me know and
we'll get them scheduled in. anything else?
<jeanne> +1, GJ thanks
Summary of Action Items
Summary of Resolutions
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/07/28 16:05:06 $
--
___________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>
www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 28 July 2016 16:11:42 UTC