MATF Minutes 2 May 2019

*MATF Minutes 2 May 2019 link: 
https://www.w3.org/2019/05/02-mobile-a11y-minutes.html

*


  Mobile Accessibility Task Force Teleconference


    02 May 2019


    Attendees

Present
    JakeAbma, Kathy, Kim_Patch, Detlev, Shadi, Jennifer
Regrets

Chair
    Kimberly_Patch
Scribe
    Kim_Patch


    Contents

  * Topics <https://www.w3.org/2019/05/02-mobile-a11y-minutes.html#agenda>
  * Summary of Action Items
    <https://www.w3.org/2019/05/02-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2019/05/02-mobile-a11y-minutes.html#ResolutionSummary>


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

Jake: a lot of resources I have to go through. I went through the 
existing resources very thoroughly. Next step is start over again and 
write something.
... pretty busy – need an amount of time to spend on writing any success 
criteria.
... pretty clear that there's a consensus – may be an option to make it 
AAA or we need to aim at AA but it's going to be more work

Detlev: I would like more input into this whole conversation on pointer 
gestures.
... the discussion on the Tuesday call moved to exclude a rather large 
part of pointer gestures which is all the sliders which can be dragged 
which so far I'd assumed would be covered by pointer gestures because 
you obviously have to follow a path with your finger to drag a slider. I 
assumed they were included. But Mike Gower made the point that they are 
not or shouldn't be because conceptually very similar to drag-and-drop. 
So there was some[CUT]
... which I just commented on I think we should include. Sliders, slide 
to reveal, giving information on options for gesture options. This is an 
interesting one because if you have a long swipe something different 
happens from having a shorter swipe. I wasn't quite sure with this be 
dragging or swiping. I thought all the examples whatever you can swipe 
you could also drag. So it's not as clear-cut separation as we might 
wish to draw line betw[CUT]
... dragging. And it's fairly easy to add controls – single-point 
actuation for dragging option. When something has to have alternatives 
and when not – not understand why that should be excluded. So today have 
made some effort to put together a coherent argument why it should 
remain in scope.
... If you have views it would be good to add your voice to that. 
Everyone seems to think that it's okay to remove dragging basically from 
the understanding – on second thought I thought that was not a good idea.

Jake: I can dive into the subject but first I would have to read through 
it all. Instantly having made my mind up would be hard to do within five 
minutes.

Detlev: it's a very large class of gestures – shouldn't be excluded, my take
... I wanted to revisit the techniques I've drafted – haven't gone 
further. Discussion about success criteria failure technique which was 
high-priority. Unless there is urgent need to start working on the new 
success criteria for 2.2 I would probably focus on looking at places 
where techniques, additional techniques or failure techniques would be 
needed to pat out 2.1 because I agree with Mike that it said gap at the 
moment. There's some ne[CUT]
... don't have the techniques yet. We get a lot of questions from developers

Jake: orientation – I was checking orientation first a couple of weeks 
ago in this mobile task force group. Should I work on the Technique or 
the Success criteria, Kathy said success criteria. Last Tuesday I was 
looking into sufficient techniques for orientation and the first one I 
think mentioned something about it in the past, using CSS to set Screen 
to landscape or portrait.

<JakeAbma> Using CSS to set the orientation to allow both landscape and 
portrait.

<JakeAbma> Use of show/hide controls to allow access to content in 
different orientations.

<JakeAbma> 
https://www.w3.org/WAI/WCAG21/Understanding/orientation.html#techniques

Detlev: looks like success criteria where you need a failure technique 
more because the technique would say nothing – don't constrain. So it 
looks more like a failure technique is needed. Same thing for single key 
shortcuts. As long as you don't do anything it's fine.

Jake: there's a lot happening to keep up with. What should we do first?

Detlev: that was discussed in the call as well that's why we have to 
move on with 2.2 in some way. I still think it's important to get 2.1 
padded out.
... and silver. it's all important and we need to divide up our time to 
cover all three

Jake: it was up in May 2019 with not a lot of techniques. We've made 
some more but it's not enough still.

Detlev: I would prefer to have less success criteria for 2.2 and get 2.1 
better knocked into shape. That's my opinion

Jake: I sent the emails – got feedback, enough to Digest for one week. 
Also it was clear on the call last week that Andrew wanted to ask people 
to work on techniques before working on new success criteria.

Detlev: related elements criterion – draft text for narrowed scope, find 
a way of measuring that in a way that would cover all potential 
scenarios, also would miss out on opportunities to for example look at 
the relationship between something like a dialoge in the close button 
which may be in the far top right corner and not anywhere inside the 
dialog – Twitter or some other well-known platforms. That wouldn't be 
covered simply because it was[CUT]
... is there any way to cover this in some way with a success or failure

Jake: it was not the distances but if I remember right – if you can have 
both a screen accessible without zooming

Detlev: but that would mean you would measure something that would 
completely change – Zoom text on a full screen desktop view where the 
window travels around a small section is magnified the problem would 
remain. So if you have enabled element faraway from each other with no 
guidance that could not be covered and that could be very common. For 
those users traversing those last empty spaces – the desktop view. Maybe 
that's an angle that can b[CUT]
... can you draw boundary around labeling labeled and it's not wider 
than something – but it still seems very difficult to nail down 
particular values

Jake: but it's the most easy part for testing
... if you take an average phone screen and it just fits in there 
without having to scroll, that would be easily testable. Basically you 
set a boundary somewhere where objects need to be in proximity of each 
other but if you use zoom text you will never accomplish the success 
criteria I think because you can zoom in 800% so you will not have the 
same proximity. But still if it's in the boundary, at least you know 
it's close even if you use zoom[CUT]
... that's the other thing that is still stuck with me for that issue. 
Calculation about where to place it and also I have some practical 
examples were some labels are small like a yes no and other things are wide
... and the way you should get the calculation was just not possible in 
those scenarios

Detlev: Question is would be a good thing that labels are far away – at 
some point will people rethink their design patterns. Wary of being too 
restrictive for designers. But I would keep that open, it's a design 
choice. That may still leave enough options to either have – arranged 
differently or have different groups. There may be all sorts of ways you 
can deal with that situation. It certainly not ideal if you have a yes 
no miles away from [CUT]

Jake: here's a link for our website – No way they would have those 
labels aligned right
... between the radio buttons and on the left side What's your age

Detlev: seems all right to me – I would think this passes, may be some 
too far away

Jake: we are on the edge of telling people how to design

Detlev: colored bands to differentiate? there are many ways of tackling. 
Wouldn't need to constrain into mandating a minimum distance

Jake: I talk a lot about proximity – but a lot to say about how to test 
it without being too strict on the design

Detlev: example you gave is interesting – label on the left is quite far 
away but there's nothing that would prevent the designer from just 
moving those – making those columns narrower so that the text to the 
left would wrap and it does indeed in some cases. Just wrap into two 
lines which are shorter and there's only one word that might wrap into 
three lines if you made that column a lot narrower and maybe decrease 
the gutter width between th[CUT]
... dragging in a control slider can't be separated from drag-and-drop, 
just following the x-coordinate of your finger. It's not directional in 
the sense of a swipe. Mike Gower pull request to remove slider example 
to constrain the scope of pointer gestures to multipoint gestures and 
simple swipe – directional movement. It's not quite clear what remains 
when you narrow down the scope..
... it's not clear whether an image slider is still in scope – basically 
the same once you pick it up you can move your finger up and down and it 
will still follow the X coordinates, you don't need the directional 
movement to follow the image slider. So it's not clear conceptually what 
separates wiping and dragging. I also made the point that what can be 
swiped can be dragged.
... also complex swipe gestures – swipe to reveal scenarios where you 
swipe to get things like file or delete appearing. Or you go all the way 
with your path then it will be deleted immediately. You know that from 
iOS from the mail app also implemented by Oracle and some web 
interfaces. I've looked at some of those examples to make the case for 
keeping dragged gestures in scope for pointer gestures. And also adding 
an example for the comple[CUT]
... reveal. Not sure if everyone is not thinking it through. I think 
it's still an open issue which needs to be resolved somehow. I would 
welcome anyone looking at that pull request and at my review of it to 
add their own view or review so we get to a more informed group position 
on this.

<Detlev> https://github.com/w3c/wcag/pull/714#pullrequestreview-233053036

Kathy: and so it's mainly the understanding document that we are 
changing – not the actual SC?

Detlev: I think the text allows for various interpretations because path 
based gestures and multipoint gestures.
... you can have another one that would describe path based gestures, 
include dragging. Speed – might be only triggered when you move with 
sufficient speed, but in my experience that may not be true in practice.
... the suggestion has its benefits, but I think something else would be 
better

Kathy: Patrick hasn't looked at this either, right?

Detlev: don't think so. Mike sent a request to Andrew and me.

Kathy: I'll take a look and comment
... I was going to put the first SC redrafted into get help for pointers 
– if you want to take one last look at it. Once we do that it will go 
into the working group. I think we've gotten that one done. And then 
it's just looking at the other SEs and the ones we haven't gotten in there.
... spacing between targets

<Kathy> 
https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

Kathy: we have the initial draft, if anyone has changes to that let me know
... I'll address Jake's comments and finalize that. I pulled an example 
from Amazon, and it fits within what we were having. I took that is one 
of the Harder cases to look at.
... it would be good to finalize the SCs that we have there, then the 
priorities after that should be going into techniques and writing those. 
But the should be to finishing these – we've started and we are close, 
while we are still into these That's my recommendation

Kathy any questions before we wrap up the call today?

Detlev: states discernible question – Mark has an action item to check 
with designers

Kathy: he got some info – it would be great if you could also if you are 
interested in that
... I just put your name next to it – this is the one where we had a lot 
of questions so if you have an idea for a proposal That would be good to 
Explore. There are usability issues – challenges how to structure this.
... a good one to do

Detlev: I will take a look

Kathy: Mark did put in carbon patterns from IBM in column J under comments


    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/05/02 16:17:02 $

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



**
___________________________________________________

Kimberly Patch

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>
___________________________________________________