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: 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.)[End of scribe.perl diagnostic output]