interactive interactions

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.)