https://docs.google.com/document/d/1ouVFq4w-i0rchNHtTAG_JoRwHfYm9mN2MkxFBct1JSI/edit
Jake: issue – if you don't know
there's a custom interaction how do you tested
... very extreme case – how do you know if you want to do two
swipes and put five fingers on The screen
Kathy: the onus is on where these things are – you can make the same argument for making sure mouse actions are keyboard accessible. I agree that's a little more Complicated but it's the same principle
Jake: I agree. It is possible in
theory that you would do some really weird interaction, but I
don't think that's a reason for not having a success
criteria
... if we had testing procedures that would be an interesting
one – what will the testing procedures be like – play around
and try to figure out if something out of the ordinary happens
while not using a standard interaction?
Detlev: well if it's using
particular touch events maybe there are ways of testing. It
might be a first step to potentially discover
... I'm not sure needs to be watertight
Jake: how far do we need to prove that everything can be tested before it can become a Success criteria.
Kim: another example is speech – if you want to test speech you would have to use a dictionary and then two and three words – it's impossible. I don't think it's practical to say you can't find custom interactions
Kathy: You can say the same of keyboard – some of the onus of testing is finding
Detlev: Conformance tests where you get asked to carry out a test but the person carrying out the test might not have access to the developer, so it's not always easy to get direct access to the developer to find out. But I think you're right it's a general problem – it could be complex keyboard interactions which you need to find out about and if they're not documented you're likely to miss some if you're not very very diligent and lucky
Kathy: it's the same issue with keyboard trap, keyboard shortcuts, testing keyboard – you can point to a number of different instances within the WCAG today. There just needs to be some way of identifying what the custom interactions are then once you know them how to test
Jake: so the big question is not
finding custom interactions, but defining standard interactions
– everything else will be custom
... Standard interactions are defined right now I removed the
shaky things and the double pointer.
Looking at standard gestures
Kathy: why are we creating a list, why wouldn't we just point to standard gestures For different platforms
Marc: that's what I was hoping for – point standard list
Jake: there are standard lists where we came to the conclusion that it wasn't standard may be for that platform. I think the standard ones are the ones common for all platforms, not platform specific. Otherwise we need to provide all kinds of lists for all kinds of platforms if they have them at all
Marc: some sort of language that would let folks know check for the standard gestures for the platform that you are targeting. In iOS, iOS lists their gestures, and if it doesn't fall within that set – gestures for your platform or your targeted platform, something like that but better
<MarcJohlic> Example: Multi-Touch gestures on a Mac https://support.apple.com/en-us/HT204895
Kathy: gestures could be different depending on what Browser you're using even. Standard interactions are things that aren't part of the documentation of the platform or the user agent that you're using
<JakeAbma> https://developer.apple.com/design/human-interface-guidelines/ios/user-interaction/gestures/
<JakeAbma> https://material.io/design/interaction/gestures.html#properties
Detlev: we're only talking about what the author is adding. There might be things that only work on test screens, for example. If the author targets desktop and mobile then it's pretty likely that there would be an alternative for that.
I thought the whole idea was to give a simple list that works across platforms
Detlev: how often with these change? I think we had discussed before that many of them have not changed for years or even decades. But with this change? Would they have to be updated frequently?
<JakeAbma> https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
<Kathy> https://developer.apple.com/documentation/uikit/touches_presses_and_gestures
Kim: take a look at the standard pointer gestures – how long have they been around and have they changed?
Jake: if we don't have a list
like this how will anyone figure out what is custom
anymore?
... we're pointing out a fairly concise list of the most basic
standards. Will we do that or point to multiple lists
Detlev: maybe it's good to have a
concise list and if there may be things that people say this is
standard, this just isn't cover it, that can be added. So if we
have a safe list that have been widely supported and around for
a long time that may be a good starting point. Pointing to
different collections becomes impractical from a working
perspective. Testers would have a very hard time doing that. If
we stick by that approach which I think is a[CUT]
... the standard stuff and everything else is custom.
Jake: that was exactly our starting point to set up this list
Kathy: the whole purpose of this SC is to provide instructions for things that are more complex – drag-and-drop causes anxiety for users. What if we took out drag-and-drop completely out of the standard list
Jake: I thought the difference
between a swipe and a drag is with a swipe in a certain amount
of time you just swipe with your finger on the screen but you
also release your finger within that swipe, while a drag is
more secure, you hold your finger on the screen so you drag to
the left like the example we have in the email where when you
pass 50% of the whole screen options appear and by the end they
will be deleted – that will never happen wi[CUT]
... but just when you drag
Detlev: I think dragging is a
difficult one you have different situations. Control slider you
drag with a certain constraint in the whole slider tells you
this is something you can drag and you have free-form dragging
which might not be detectable – you can pick up things and move
them somewhere or target areas highlight and you wouldn't have
known. I think it's a tricky one
... there are some well-known cases where there are enough
affordances is for users to guess, maybe not all users but most
users to guess
Jake: strict drag, free-form
drag
... not a free-form, but a straight drag to get the options on
the menu. So we use the same definition for drag?
Detlev: the email example move halfway and the element follows the finger and you can move back and forth is a drag, and swiping is more like you push something and it moves. There you wouldn't have find control about how far it goes
Jake: so we wouldn't remove drag, but remove free-form
Kathy: I'm wondering if we take drag out altogether from a standard interaction – any drag function regardless if it's dragging and holding in a fixed spot, dragging and dropping a list, doing any of those is not what we consider A standard
Detlev: you could argue that the
groove under the thumb is an instruction which defines the
constraints of the Dragging
... so take out drag altogether and use that is an
instruction
Kathy: we'd have to add that in above as an instruction
Jake: I agree with you Kathy, if you have a drag, let's say you want action with the drag element when you swipe it
Detlev: some may need initial
engagement before – dragging a slider
... maybe you have coverages with left right up down. Someone
could come up with a slider which is just as common but rotated
by 45°, so you'd have a diagonal slider which would probably be
understandable but would that make interaction non-custom?
Kim: this is a moving target – 20 years ago none of us would've understood any of these. We have to make a list that works now. I like what Detlev said about the slider groove being instructions. If that were the case then if somebody did a 45° slider, they just have to make it look like the familiar slider And the change works.
Detlev: I think this is a sound approach – we need to see what people think
Kathy: I would take out pen because you can do all kinds of things with a pen
Jake: maybe we should say the F keys are already used by the operating systems
Detlev: so they probably should not be on the list
Kim: agreed, they're not on mobile either
Kathy: I agree, I think we should
put it out to the working group and get some feedback and
continue working on it
... there was one comment – we should finish that one, and then
will have a document you can go to the working group with
... this is ready for the working group
It looks like some folks can't make the next meeting on the 19th, then the next two weeks are holidays. Next meeting will be January 9.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: Kim_patch, Kathy, JakeAbma, Jennifer, Detlev, Marc Present: Kim_patch Kathy JakeAbma Jennifer Detlev Marc No ScribeNick specified. Guessing ScribeNick: Kim_patch Inferring Scribes: Kim_patch Found Date: 12 Dec 2019 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]