<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