<Kathy> 2. zakim, this will be 6283

<Kathy> meeting: Mobile A11Y TF

Kathy: going over changes to success criteria and understanding document

Detlev: understanding for 2.6 but too late to be included in the draft – there is text in the respective github branch
... some feedback (Joanne Taylor)
... replied interesting point but we should just cover motion actuation rather than splitting it
... I think the use cases are pretty close, techniques would be that different. There's a good case of keeping it simple. I've drafted the responses.

Kathy: Suzanne is doing gaming development just to give you perspective about where her comments are coming from

Detlev: good points but they could be covered by a separate success criteria.

Kathy: in 2.2 or silver. it's important to capture that
... looking at all the changes – there were days and days of multihour meetings and a lot of it came together quickly in order to get this into this current draft. There were a lot of changes to quite a few of the different success criteria.
... in reviewing all of these one of the things that I think got lost and we might want to revisit is the whole 3D touch aspect
... to recap where we are in what happened with some of these the major changes happened to the ones that Kim listed in the meeting agenda:

2.5.1 Pointer Gestures (No understanding in linked document) 2.5.2 Pointer Cancellation 2.5.3 Target Size (No understanding in linked document) 2.5.5 Concurrent Input Mechanisms (No understanding in linked document) 2.6.1 Motion Activation

TOPIC 2.5.1 pointer gestures

the understanding for this one really needs to have a lot of things included so this can be understood but now it is multi-points or task based gestures

Detlev: not linked to understanding – there is a draft
... comments – want to emulate long presses. I've change that – single-point activation seems more precise but I'm not sure

Kathy: glossary single pointer definition one point of contact from the screen

Detlev: that would not cover double-click. Maybe concern partly alleviated already – split between web authored gestures and other gestures from user agent or operating system – some concern that this would be too restrictive
... I'm not quite sure if this can live the way it is or we need an exception
... to cover multipoint gestures, taps
... I sent this to the list to discuss but I think there's too much happening

Kathy: putting together a list of everything that we need to talk about – this needs to be part of that
... I'll make sure that that gets in

Detlev: I'm not sure whether the examples are sufficiently complete to cover the different complex gestures – there could be more work to be done on that

2.5.2 Pointer Cancellation

Kathy: this is allowing you to do drag-and-drop because the final completion of the function is on the up event

Detev: this is easy to misunderstand – the moment you put your finger on the thing and drag it you can see the other box highlighted and tells you where to move it – you can undo it but you would already execute the part of the function, the highlightI don't know whether that counts is changing, but it could be seen as to restricted

Kathy: this always trips me up it says at least one is true so you don't need all four of them
... the other two are up event reverses and completing the event on the down event – if any one of thoseour true
... understanding needs more

Detlev: might be interesting to see the BBC requirement

Kathy: we did go back to that at TPAC – might be good to look again
... Melanie if that's something you would be willing to do, that would help. In the minutes from that marathon of because it would be good to capture what was said about this one – there was a lot of talk on drag-and-drop, abort, undo. That needs to be incorporated into the understanding document. If we had that in one place that would be easier.

Melanie: will pull those out and put them in a doc

2.5.3 Target Size (No understanding in linked document)

Kathy: main change is AA we changed the size. By having a 44 x 44 it was breaking too many different scenarios. Many varying opinions on this one. Push it through by saying we know it's an issue in many areas, menus, blocks of text even within form fields. So 44 x 22 and block of text exclusion so there's a big out.
... it does mean that things like different menu links do need to have 444 x 2222

Detlev: usability argument against making this requirement
... not sure that it's best in all situations in all cases

Kathy: I think there's a lot of trade-offs that we make every day in a lot of different things. Trying to balance. If we can get some 22 x 44 it's going to help. If there are other cases where it can't be done that's fair. And then AAA 44 x 44 except in line targets

Detlev: it needs to be tried out whether it's feasible or not. It certainly feasible if you have different views

Kathy: Microsoft is already solved it – when you hover over there buttons they pop it out and make that button that has focus – the target size bigger

Detlev: would it needed differentiation in terms of focus

Kathy: I'll make a note now that we need to add that to understanding

Melanie: one of the questions we wrestle with is doing make a success criteria that puts it on content authors when user agent is the best place for
... example when I touch it the browser will blow up that area so I have a better chance of hitting it – I've never figured out how my phone knows to do that or when it doesn't because it's not consistent but is something that thinking ahead

Kathy: exception bullet number three is that scenario
... if the user has locked in the size it is excluded

Detlev: operating system controls like zoom – if you turn that on, triple tap on the screen then move around everything is bigger but you have to pan the screen to get to your target – you can always use browser zoom or built-in operating zoom to increase target size – that's a different issue

Kathy: to a certain extent you have the same thing with zooming to 200% and that success criteria. There are certain scenarios where that is a problem but it is for the user agent

Detlev: target size discussion – user agent or operating system way would already be sufficient? That would make it be easily met. Authors wouldn't have to do anything. Just to understand this user agent control exception – was that a point of discussion

Kathy: discussion the week after Thanksgiving. If you just change the color have you really changed. The problem is if you modify the target size you will prevent certain functions from working. So if you walk in the target size
... if you lock in the different controls
... the conversations have gone from what is the change that is going to matter to what can we say is going to be kind of a native where you haven't modified – I don't care about the colors, just the size of the target
... time for the other call – if you can take aa look at concurrent input mechanisms and motion activation and let us know if there any concerns about those

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)


WARNING: Replacing list of attendees.
Old list: (no_one)
New list: Kim Kathy Detlev Melanie

Default Present: Kim, Kathy, Detlev, Melanie
Present: Kim Kathy Detlev Melanie
No ScribeNick specified.  Guessing ScribeNick: kim
Inferring Scribes: kim
Found Date: 14 Dec 2017
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)