See also: IRC log
<trackbot> Date: 06 August 2015
<Kathy> meeting: Mobile A11Y TF
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/thread.html
Kathy: discussion on touch – not just for mobile
Jan: Patrick made the same comment – mouse and pointers play into this. It's a good start but it needs work. It's a whole new branch of the document and so obviously it will need work to go forward.
Marc: when I read through it what
stuck out was a grid – touch target borders are up against each
other. Do we need to have a differentiation between when
something is in a grid versus when it's an icon on the
mainstream. That seem to be the thought that most of us had
when we were first talking about touch target sizes and spacing
between them. The visual I had was the landing screen and
an...
... app icon
Jan: I didn't see a big difference there – when the device makes a calculation of where your finger is you got this blob and a midpoint. I don't think there's a huge difference if there things up against the borders are not
Marc: but okay and cancel button – if they're too close
Jan: size issue – you don't see one pixel by one pixel mouse items out there
<jeanne> Touch Target Clearance: The center of each touch target has a distance of at least 9 mm from the center of any other touch target, except when the user has reduced the default scale of content. (Level AA)
Jan: if you do that calculation you find that all the little rectangles need to be 9 mm wide
Marc: spacing between them?
Jan: that would be nice but grids are popular
Kathy: 1 mm clearance, that would be 10
Jan: if there are really large things next to each other are we still requiring the 1 mm clearance? I think we really only need touch target size and just say they don't overlap
Kathy: I think the one pixel
clearance came from the BBC guidelines – not sure what their
reasoning was for having that in there. Henny would know.
... the problem is if it's overlapping then you have issues
Jeanne: but if it's overlapping it wouldn't need 2 by 6
Kathy: the other thing is this
isn't restricted to mobile, you have touchscreen whether that's
laptop or tablet. Thinking here we are tailing directly to
mobile but should it be mobile or should it be in the mobile
extension and then in other extensions – it's a different way
of interaction it's not necessarily restricted to mobile. So
I'm wondering – there are a couple of different things...
... that can happen – one this can be more on the interaction
model rather than on the mobile side or we can have it in a
couple different places or rename to interaction patterns
Jan: I think it makes sense to talk about in the mobile group because we have a mobile group but realize that it applies to other areas – another would be kiosks it applies there too
Kathy: is there an extension for kiosks
Jeanne: rarely web
David: amend name to mobile and
touch?
... lots around touch, this is a good bucket for it, creating a
new task force tough to do, a lot around cognitive.
Kathy: it is a good component to mobile
Jan: I don't understand why this is something we have to get into – pretty something that is well worded
Kathy: just in the wording to let people know where to find it if it's buried in the extension some people who are doing such access and other devices may not find it. The idea is to think about different interaction. I agree with you we don't have to worry too much about it I just don't want it buried
Jan: maybe when we do an
extension we group them together as modules and then say mobile
uses these
... you could have your touch extension your smallscreen
extension and your shakable devices extension and then you
could have an umbrella over that and say here's the mobile
devices metaextension – it includes these three extensions
David: two layers – mobile and touch and touch applies to both – get complaints about number of layers
Kathy: were going to find there is much more overlap between the extensions – if you look at cognitive, educational or other extensions we are going to have things that are going to overlap so were going to have to figure out how to handle it anyway
Kim: trouble with mobile and touch is it leaves out speech
Kathy: need additional things for speech – naming of controls – there are things that go beyond that we really haven't addressed speech at all in WCAG
Jan: speech is a little different than touch. People will think I'm not doing a speech app. If I'm a head mouse user I would want to follow mouse, but if only keyboard it would leave out a head mouse user. How do we somehow draw out this idea that there are these ways of interaction – mouse is usually considered and speech
David: I've never seen a problem with mouse user only – even head pointers can use on-screen keyboard. Is that a real problem or theoretical
Jan: I have run into it talking with a guy from Neil Squire society – android device had mouse so he could use his assistive technology. On-screen keyboardversus mouse
David: usually wouldn't tab with an on-screen keyboard
Kim: you need both for speech users you can follow keyboard or mouse but sometimes one not appropriate, keyboard is important
Jan: you need both
... and then the speech access lies on top of that – the
messaging is tricky and speech. You can't just say your
application needs to be controllable by speech because people
are going to say what steps should I take? Have a keyboard
interface I already knew I was supposed to do that. What are
the words to not turn people off
David: modules – as a matrix? The touch part, the voice part, getting complicated
Jan: depends on how many modules there are – we publish some modules, let's say touch, smallscreen, i can see voice control as well, and then the recommendations that most mobile applications will be using these conditions
David: so we wouldn't have an extension based upon mobile, just extension based on smallscreen, touch and maybe speech and maybe something else
Jan: it could be a mobile profile. I would like there to be a page that if you searched accessible mobile application that would come to a coherent page with a coherent message
David: it makes me nervous I just hear so many complaints about how complicated WCAG is, mobile extension, touch extension – unless we have a really great model, right now WCAG has
Jeanne: what is a guideline but a module
David: how would that fit in – I was thinking that we would come up with a whole bunch of success criteria and we would be able to fit them into WCAG
Jeanne: why couldn't we plug in a whole guideline – I like that idea
David: what would be an example of a guideline
Jeanne: touch access needs to be accessible, here's the first success criteria. Detlev's proposal: touch accessible… I'm not saying that should be the final wording
Jan: I'm with you Jeanne. A few bullets, we've got to meet WCAG 2, which is at this URL and these two or three other things which are at these URL's. They have to be consistent
David: I can see guideline – have to provide touch based alternatives
Kim: making it obvious what's necessary to make something touch accessible, speech accessible etc. Speech needs keyboard and some other things touch needs mouse and some other things. Important to have this knowledge
Kathy: Part of what we started
looking at with mobile touch, scripting etc. a matrix of
different requirements different techniques for different
things. I agree with you David it gets very complex. The
challenge is how do we actually communicate this to everybody.
We are already complex within WCAG and then with the extensions
more complex and then repetitions throughout that.
... the reason for doing HTML was not being repetitious with
technologies. Same model but getting into interaction mode
versus technology. Different ways of interacting with devices,
with computers with whatever digital media we are using. And so
when I keep coming back to this my thought process is always
back to what are the different interaction modes and what are
the different things...
... that are important here. Because we are going to have those
interaction modes across different types of devices whether
that be mobile, kiosks, laptop, Mac, everything.
... it's not just mobile techniques it's different interaction
models whether that be speech or touch, that we think is
important. When we are looking at the accessibility support
under WCAG we are telling organizations what their
accessibility support should be and based on their audiences
and everything else the interaction model should also kind of
follow what it is and what the...
... audience they are reaching out to. For example if they have
an application that is specifically for a particular audience
they wouldn't have to support certain interaction model for
example. I haven't thought through it all the way I just keep
coming back to interaction models. And that is really the
differentiation
... when I look at mobile all the principles we keep talking
about apply to mobile – interaction models aren't changing, the
primary interaction model with mobile is touch. Our primary
mode of interaction on the desktop is mouse and keyboard, but
not the only way. When we get to what are the differences the
only differences really are the operating systems, and when we
get into the...
... preferences for interaction. I haven't figured out where we
should go with this but I keep coming back to those key
points
David: I think there are a huge
number of people who just want to see WCAG updated – throw out
the extension model and just update WCAG. I'd like to see us
come up with a whole bunch of missing success criteria and we
have a charter in a bucket to put that in.
... try to get them into WCAG and as soon as possible Grid
model is going to get really crazy really quick. What I've been
teaching webmasters is the guidelines and the principles are
just buckets for the success criterion. They really aren't
anything but to help you categorize the success criteria in
your mind. I'm thinking if we can get a whole bunch of new
success criteria – touch,...
... three success criteria under that, I think if we do
something like that can do it pretty quickly. We can come back
with an extension that works and will be fast.
... one of the things we had in WCAG that we don't currently
have right now, is Grant and Dan and Greg working full-time –
we don't have that now. I have some concern about that and I
think it would be really great if we could just go with mobile
and touch and get them plugged in as soon as possible
Kathy: we've gone down the path
of touch criteria, and that this isn't just mobile. In the long
run these aren't going to be just mobile techniques or success
criteria, these are going to be more integrated and as long as
were thinking about that as we go we can go through and create
some success criteria in our area of mobilebut we need to make
sure that those aren't going to be pigeonholed...
... just for mobile
David: I think we can get an extension just for mobile and touch – that expands our scope and allows us to create a guideline for touch. Because mobile going forward is so much speech we may want to make a guideline for speech in this, if we want to decouple them later we can
Jon: I hope it fits into the charter
Kathy: do you see issues of this not fitting into the charter?
Jeanne: we need good ideas – I
think this would work I like it. We should decide what we think
is the best thing to do, propose that and keep working. Crank
out the success criteria, techniques, writing
... if we keep it modular we can rearrange it as we need. The
hard part is getting the stuff written
... focus on what's the best thing for accessibility and keep
pushing that
Kathy: this is been a great
discussion – anybody have any other points they haven't
vocalized yet?
... for next week we've got a couple of people who been working
on techniques who have something already – I'm going to publish
a survey based on what we've got. If you have other techniques
that are written and are ready – if you have ideas for other
success criteria let us know and we will continue discussion
next week.
... any questions about techniques they are working on or need
any help with anything?
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) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim WARNING: No "Topic:" lines found. Present: Kathy jeanne marcjohlic Kim Patch Jan David MacDonald Jon Found Date: 06 Aug 2015 Guessing minutes URL: http://www.w3.org/2015/08/06-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]