MATF Minutes December 12, 2019

*MATF Minutes December 12, 2019

Link: https://www.w3.org/2019/12/12-mobile-a11y-minutes.html
* *
Text:*


  Mobile Accessibility Task Force Teleconference


    12 Dec 2019


    Attendees

Present
    Kim_patch, Kathy, JakeAbma, Jennifer, Detlev, Marc
Regrets

Chair
    Kimberly_Patch
Scribe
    Kim_patch


    Contents

  * Topics <https://www.w3.org/2019/12/12-mobile-a11y-minutes.html#agenda>
     1. interactive interactions
        <https://www.w3.org/2019/12/12-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2019/12/12-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2019/12/12-mobile-a11y-minutes.html#ResolutionSummary>


------------------------------------------------------------------------


      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.


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes manually created (not a transcript), formatted by David Booth's 
scribe.perl 
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 
1.154 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2019/12/12 17:06:39 $

___________________________________________________

Kimberly Patch
(617) 325-3966
kim@scriven.com <mailto:kim@scriven.com>

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

PatchonTech.com <http://www.linkedin.com/in/kimpatch>
@PatchonTech
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________