Mobile Accessibility Task Force Teleconference -- 02 May 2019

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

- DRAFT -

Mobile Accessibility Task Force Teleconference

02 May 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output