MATF Minutes April 2, 2020

*MATF Minutes April 2, 2020

Link:  https://www.w3.org/2020/04/02-mobile-a11y-minutes.html*
*Text:*


  Mobile Accessibility Task Force Teleconference


    02 Apr 2020


    Attendees

Present
    Kathy, Kim_patch, Detlev, Rachael, alastairc, Chuck, Jennifer, jldailey
Regrets

Chair
    Kathleen_Wahlbin
Scribe
    Kim_patch


    Contents

  * Topics <https://www.w3.org/2020/04/02-mobile-a11y-minutes.html#agenda>
     1. touch target
        <https://www.w3.org/2020/04/02-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2020/04/02-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2020/04/02-mobile-a11y-minutes.html#ResolutionSummary>


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


      touch target

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

Kathy: on the last meeting we talked a lot about adjacent targets and 
how that got lost in the going back and forth
... Alister, I see you've added some changes – we can look at that. We 
should probably also start looking at the understanding part and update 
that because it still has a lot of the old material in it
... Alister, do you want to talk about your changes to the language and 
what you are thinking?

Alister: we went through about 15 different changes on the call.
... it always felt like we were almost there and then we spent an hour 
and three quarters going back and forth on it. It was things like where 
to put the each, it was a fairly, regional point from Wilco about what 
does targets mean. And I think he followed up later about even though we 
have a definition, he was talking about Why that's not appropriate

Kathy: don't have adjacent target definition

Alastair: we get reasonable pushback on trying to find dictionary terms

Kathy: it seems like there's a lot of confusion still going around with 
what were actually aiming for here in trying to solve and that also 
looking at the different user needs
... there are things like when you are using speech for example we don't 
want to have a list that goes off the screen. When you're looking at the 
spacing between for those With a hand tremor – all of this is trying to 
balance the needs between different user groups
... some of what is in here stems from those two requirements

Alastair: almost needs time to settle. Multiple bullet points we tried 
that version for a while. Then we worked out, actually the second of the 
bullet points as a superset of the first bullet point, so then we went 
back. If you look at the minutes from the meeting it just went on and on.

Kathy: I did review that, but at the end I got confused over what it was
... my general feeling was that if we could clean this up and really get 
the plain English summary and more description on how to tested I think 
that might go a long way.
... I like the rewording, I think it's fine. I'd like to get others 
opinions to. It basically states what we were getting to. I like 
Detlev's new Diagram that we can use to further communicate what we're 
talking about

Detlev: I'm not sure – I don't have a real grasp of what were work best. 
My focus is working out all the permutations of work targets can be 
placed. Questions raised – what if presented as a cluster – Need to have 
an answer on those, less concerned about the exact wording.

Kathy: are there any scenarios you been thinking about that need another 
exception for

Detlev: examples – the graphic I sent just before the call, there is a 
role of buttons. Fairly narrow, 12 point height, just a small word and 
it of a length where the width this always 44 as long as there's nothing 
above and below that Row it would meet the success criterion
... but nothing to say spacing is evenly distributed – I don't know 
whether we can close that gap or if it's likely to be an issue

Kathy: that's a good education
... that's a good edge case

Detlev: The edge cases are difficult because there's nothing else to 
come in adjacent terms but would we want to prescribe the spacing be 
even? I don't know if we want to go down that route.

Kathy: I think it's going to be difficult to get all of those edge 
cases. The language that we have here without that requirement will 
solve the issue for a majority of the targets. We have to decide as a 
group if we want to go down the path of saying we have to do this 
because then we also get into the issue for reflow which is what we got 
into for target size. Any of these could be a problem when the screen is 
resized as well.
... If you combine that with your failure, it's no longer testable and 
hard to get into 2.2. We have to think about that and what we want to 
look forward to. My general Feeling is there's going to be scenarios 
like this and when we go to a responsive layout but I don't think we can 
solve for everything.

Detlev: at least there are some questions like the last case, if there 
is a block of text above the last row, since we have an exception for 
in-line links does that mean that they are not taken into account in 
space and calculations – that's just an open question. You could argue 
both ways. They are targets so you can accidentally hit the button just 
as well as you can accidentally hit a link.
... Or you say those are exempt anyways so they will not go into any 
kind of calculation. I would want to make language clear in 
understanding that says any cases we've taken into consideration

Kathy: added diagram to document

Alastair: in-line links are exempt, other links aren't exempt, but 
in-line links would still figure into that calculation as adjacent targets

Kathy: target is links or buttons or any other control, so The links 
above are targets

Alastair: there's an exception for links that are aligned but that 
doesn't apply to links that aren't in line like the menu. It's a good 
example

Kathy: so the buttons would have to have a 44 x 44 to the text above 
because there's only a four pixel gap right now, and only two pixels 
below So we only have 26 between the Link and the button

Detlev: so if the text weren't there it would pass because both top and 
below you have enough space

Kathy: pretend the text Isn't there and those two rows are flush 
presumably it would pass because we don't say the spacing doesn't have 
to be even

Alastair: That makes practical sense because I could aim above the 
button or below the delete button. So in a practical sense that is 
making it easier

Kathy: so in this case the failure those buttons would have to have a 44 
CSS pixels between so you couldn't have them butt up against each other. 
At the top there's not a 44 width around them

Jennifer: Am I remembering wrong – one of the original wordings padding 
something like eight pixels

Kathy: yes – we played around with that, but ran into problems

Alastair: sets up a weird incentive where you might want to shrink the 
targets
... I think half the time we're spending on criteria at the moment is 
expanding why we didn't go down particular dead ends

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

Kathy: so what we have right now is adjacent targets combined with the 
spacing between targets have minimum heights and minimum width of at 
least 44, in-line exception

Alastair: each

Kathy: yes, we added each last week to make sure of that

Alastair: has anyone seen any comments that would justify change at the 
moment? My feeling is we probably want to go through the comments and 
make sure there are answers to everything but I'm not sure there's a 
beneficial change to make it the stage

Kathy: can we go through one by one

<alastairc> Wilco's & Andrew's comments from the survey (table 1 at the 
bottom) https://www.w3.org/2002/09/wbs/35422/target-spacing/results

Chuck: one of the things that came up that I don't think the success 
criteria is intended to address but it was a concern mentioned so I 
wanted to raise it here – I'm not concerned by but see what you guys 
think. Regardless of this particular wording there was still the 
possibility that you have an excessively large target adjacent to an 
excessively small target.

Alastair: I think that issue has to do with measuring from the center of 
the targets rather than the current text which is about the size plus 
spacing of the target

Detlev: would you interpret that use case as requiring that the gap 
between the tiny wee little target and the huge target – can they sit 
flush one next to the other?

Alastair: I suppose you can have 100 pixel square next to a 10 pixel 
square and if there's nothing on the other side of the 10 pixel square 
that's a very small target. But you can aim to the left of that. We have 
an SC for small targets.

Detlev: the typical tile which contains content and on top of that you 
have a read more kind of thing

Alastair: if one is inside you have the 44 x 44 minimum. That makes 
sense because There is no space around it
... the small target inside the big target has, but the small target 
beside the big target has space
... I think it's a fairly robust principal. It's just a matter I think 
of arguing for the success criteria text and clarifying in the understanding

Kathy: I don't think were going to solve for all edge cases because we 
would end up with such involve language that would be hard to test it
... click away mechanism comment – the first click tab removes the 
additional layer and a second click is required to trigger elements in 
the background which becomes again the primary layer as the additional 
layer was dismissed with the first click

Alastair: so imagine you've clicked on something one of those modals 
with the dark background behind it so the dark background becomes a 
target, look away the dark background disappears and then you have 
access to the targets behind that

Kathy: I think the layer exception does resolve what he is doing, maybe 
suggesting as a technique of how you could best implement this

Chuck: I'm gonna repeat what I think I heard – our current layers 
language already covers what I think he said. And I agree with that if I 
understand correctly

Alister: I think it's orthogonal – language there was intended for 
menus, but what he's talking about is where you have a state of 
interface where lots of the targets are overlaid and you can't get To 
them anymore

Rachel: I think the answer is this does apply to all of them – I think 
we can just state that click away applies but it's a broader application 
than just that and then resolve This

Kathy: I added Modal dialogs
... if you have a modal dialog showing on the screen and You can't get 
to the background targets, it no longer applies. You don't have to go 
from this target to the total dialogue because the background controls 
are no longer in focus and are not part of the actual content that you 
are interacting with

Chuck: I think we are continuing to hear that there's no changes to be 
made to this language

Alastair: I'm just going through Wilco's to see if there's anything else 
we haven't brought up – minimum width and height, two buttons with a 
particular height, horizontally next to each other. I think they pass, I 
think he's misreading.

Detlev: he might've missed that height doesn't have to be as long as 
there's a space below

Alastair: even though the combined with is not 88 pixels they can pass 
if there is space on either side

Chuck: two adjacent targets, they could be less than 88 combined but 
because 44 works to the left and 44 works to the right we meet the criteria.

Alastair: yes

Detlev: to go back to the graphic, pushbutton passes but pop button 
fails because it has targets on both sides So there's no space to take 
into account

Kathy: techniques – measuring margin to ensure that there's 44

Detlev: there's a flex property, can't remember the right name for it, 
that makes sure your flex element doesn't get any smaller than x – flex 
shrink zero. That could be used in a flex box situation to prevent 
things from getting too small.

Alastair: or something simple like applying a mid width

Detlev: so there could be several simple and atomic techniques

Alastair: could be applied in different scenarios small kind of fairly 
granular techniques make sense

<jldailey> be right back

Alastair: started our apply to Wilco I think we've addressed his concerns

Kathy: might be good to have Wilco on a call to make sure

Detlev: I watch, for example you have around cluster of icons which are 
not aligned linearly horizontally or vertically but which are arranged 
in a particular way with a certain distance. Would this just not apply 
because things are nnot aligned vertically or horizontally

Kathy: there are things in the eyewatch – expands as you interact

Detlev: you would probably need some kind of measurement by measuring 
centroid's of all those elements – I think that is something Wilco was 
getting at maybe because it's easier to automate
... would we say we're not covering because it doesn't apply

Kathy: I think we need to look at implementation to see if that's going 
to be impacted or not or how you do that calculation – I haven't seen 
that on the web

Alastair: I don't think it's true to say that everything is boxes 
because you can do shapes now.

Kathy: don't you have margins or padding on that too – you have a 
minimum size– we are specifying height and with. So I don't think you 
would have to do all of the calculations Detlev that you were thinking

Detlev: is adjacent confined to horizontal and vertical

Alastair: if it isn't issues with other Sc's as well

Kathy: I think will be covered by just looking at height and width

Chuck: There were some concerns toward the end of the call that resizing 
should be an exception

Kathy: that's already in there

Detlev: but that's not the same as resizing with the Browser zoom

Alastair: discussion on the long call is it would be good if you resize, 
but no way of measuring That – no real mechanism for us to say X 
centimeters, went through that with reflow before. I left it on that 
call as if anyone can come up with a mechanism for measuring that's 
great but otherwise we can't use Zoom as a mechanism to pass

Kathy: we went through that on the AAA one

Detlev: argument that we shouldn't use Zoom to pass. Others – since 
every small text can be made large you could argue that. Also the 
disadvantage that you lose context should disqualify that

Alastair: it would help to rename the title of that exception from 
resize to something else

Chuck: enlarge?

Kathy: how about we put the CSS pixel size in their sword drives home 
that were not talking about just zooming?
... changing wording to reflect that

Detlev: sounds good to me

Rachel: I think including the additional CSS pixel is good

Kathy: so maybe we're getting a little closer?
... I'm fine with what we have here. We can update the intent language 
and address some of those things before next Tuesday. Is there anything 
else that you see – that you guys would like before Tuesday?

Alastair: Need a technique

Rachel: this will be toward the end of the meeting on Tuesday

Kathy: at the end of the meeting I'll be on my daily call

Rachel: I'll ping you if needed

Alastair: we can sort out an email before if possible


    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: 2020/04/02 16:04:24 $


*
*___________________________________________________________

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