<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
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
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.)[End of scribe.perl diagnostic output]