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

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: Kathy, Kim_patch, Detlev, Rachael, alastairc, Chuck, Jennifer
Present: Kathy Kim_patch Detlev Rachael alastairc Chuck Jennifer jldailey
No ScribeNick specified.  Guessing ScribeNick: Kim_patch
Inferring Scribes: Kim_patch
Found Date: 02 Apr 2020
People with action items: 

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