<JakeAbma> Script for calculating distance between UICs

<JakeAbma> https://www.w3.org/WAI/GL/mobile-a11y-tf/track/actions/77

touch target

the actions link above has responses from Sean and Wilco and also Alastair

thinking about the responses

Jake: looks pretty complicated, testing looks like you might easily get false positives. We have to get practice

Detlev: run a script like a bookmarking it would point out things that were potential problems – that's useful. Fully antiquated, though we might run into problems, but that's just a guess

Marc: still trying to digest it – trying to figure out what he means by scrolling something

Detlev: presumably scrollable area and some directly above it so if that scrollable area had in-line text links could get close to the button – not very likely to happen but could be a problem. Or maybe they mean something else, that's just a guess

Jake: scrollable regions or menus, submenus, pop-ups, popovers with close buttons and they go over parts of the page which is already a button. And you still require eight pixels
... let's say you have a submenu, those submenu items float over the main content, those submenu items and drop-down menu only at the border, they fail if they are over an interactive element

Detlev: would that be the case if a submenu is open above something – the requirement would hold for the submenu itself so you have enough distance between the menu items but not for something that may be underneath because if you don't have that than that would always require quite a big padding around any menu. Maybe that's good I just wonder whether that's something that might be excluded

Jake: yes but that automatically means that we basically have to go into much more detail and digest all the possible scenarios and see if we need to exclude a lot of them for all kinds of different reasons. That is what came out of these first comments, that we didn't think of all the different possibilities when it can still touch each other overlap each other and so we need to take that into account to

Detlev: maybe that's a good thing requirement having a padding around interactive user controls for anything regardless whether it's a pop-up menu or popover kind of thing, dialogue and so on. They could always have padding of eight pixels so it would assure that whatever they said above would be – would not get too close. Eight pixels is not a lot. It's probably doabl
... maybe there are cases where you have a long menu with a lot of items, but that's already an issue in the base menu
... I think I would retract my suggestion to have an exception – I think it's good to have it as a uniform and general requirement

Jake: on the other side you can say if they make touch targets 44 x 44 they pass anyway
... not that it is specifically aimed at responses, but we were looking@amazon.com last week and they only have a 42 pixel high submenus, only to pixel padding
... hamburger menu
... the comments – what exactly are we measuring
... eight pixels, but the long side from one corner to the other, I never thought about that, if the corners touch. It is eight pixels but from corner A to corner B

Detlev: how exactly would they be measured?

Jake: my guess was always, and also Sean's thinking that he mentioned here, CSS pixels between 2D – just calculating from zero position in calculating the corners
... that's the easiest one not specifically from the center
... it's the distance between the closest points on the boundaries of the interactive spaces as Sean mentioned
... the hard thing – what we did not do yet is if they change the viewport there might be a different calculation. This whole calculation is specifically needed when use percentage or flex box

Detlev: you have to set certain viewports to carry out this test

Jake: yes, one pixel viewport otherwise if you have one 1020 pixels you would have to calculate 1020 times potentially.
... that's the problem with flex box. We also have to think about that because I never have my browser full width. Every time the distance can be different when you use flex box
... reflow where you just say test at 320 and that's it.

Detlev: would that not be a way of checking on flex box items if you have margins that would not have one bothering the other

Jake: at be easy unless you use negative margins or positions
... if you use patting you're fine with interactive elements

Detlev: but padding would still be part of the touch target area in many cases

Jake: padding and link in there you'll be fine.

Detlev: also fixed position elements like page up box which stays always in the bottom corner
... that may be what Sean was talking about when he was talking about scrolling

Jake: so there's double the details – some parts that are not as straightforward as we'd hoped, as usual
... I think best solution if we want to continue with this is to have the 2D test with the boundaries based on the rendering on the screen and at least say – the difficult part is when I started with mentioning flex box or percentages those are exactly the ones not measurable
... another side of this – if this is specifically aimed toward mainly a touch targets which most of the time I think you open the browser fullscreen, I think this one is more aimed at mobile devices than desktop devices than mouse or keyboard. So will not happen that much
... but still we have to say the 2D test must be done for certain sizes – the most common sizes

Detlev: discussion – I remember when we were drafting the target size success criteria and we also talked about spacing at some point and there was at least at some point the concept that we might have different requirements for desktop and for touchscreens because mouse users would not – would have more fine-grained control over things so they may need a lower distance
... that has not been taken any further, right, we are at eight pixels whatever environment at the moment, correct?

Jake: I think there's always been a Detlev who has been telling us there are enough devices around now between tablet, laptop, touchscreen etc., so the lines blur

Kim: what's wrong with testing at several different common sizes – I think that's a good solution

Detlev: we have reflow now testing with just a few sizes, it's just one success criteria and there are suggestions that should be up to a certain size instead
... it would be best if it could be tested more, but it's difficult of this would exclude this one is not testable simply because of that. I don't think it's doable to test the entire range of potential viewport widths that we find in the wild
... I could live with just selecting a few like 1280 since it has been picked somewhere else as one size and say maybe 320 is another size and start with that. But it is not really, it is a bit of a problem. It would be nice to do it without

Kim: it be even better if we can find a better solution, but if it's between nothing and several common sizes, common sizes might be practical

Jake: checked out something Sean pointed out – Amazon example
... where you have a dialog your whole focus managers should stay in the dialog itself. we go to Amazon.com and list menu and it covers the whole page with only their menu, but when you turn on your screen reader you can interact with what's underneath the open menu
... the interactive elements overlap so they are stacked on top of each other so when you turn on your screen reader your focus can be under the drop-down menu on another element not part of the drop-down menu but part of the page

Detlev: so the issue is that it this point you don't know whether you would market as a failure of 1.2 or of this new criteria is that the issue
... I don't think we have a failure for this one although it's a usability issue for sure

Jake: underneath that menu are interactive elements so they are all at eight pixel distance. It's a weird combination but I just checked it out and yeah, we have to think about it

Detlev: if we think about touch target spacing there would probably be a failure if there are targets to close together so now you run into a situation with some links sits in a modal dialog which does not hide the background so I can get to the stuff underneath. That is a failure first of name rolevalue because the background should be hidden. so that's a failure. Also to touch targets are too close together, so do you list as failure as well, or is failure
... due to the first one

Kim: so is the issue we can test with just a few sizes or it's impractical? Is that our choice?

Marc: I think that's the issue. Discussion has slid away from accessibility. It's starting to look overly complicated and hard to test. If we said for the two or three different resolutions, okay. But I'm like you Jay, my browser is usually just taking up a portion of the screen

Kim: if you at least give people the option for common sizes, they can get the job done rather than be blocked

Marc: I might argue it's a problem for everyone

Detlev: it is harder for people with disabilities
... that would be something, if those break points are more likely to meet them than other breakpoints – even if it's not perfect if the alternative would be its untestable because of the millions of different report dimensions that are possible and I would easily go for a restricted testing set up even if it's not perfect

Marc: I think that's the best way to approach this one. Having set resolutions and full-screen – to take all the variables out of it, kind like the reflow one

Kim: most things that are better for folks with disabilities are also better for everyone, so it's difficult to entangle disability issues versus usability

Jake: at TPAC we have been looking at 44 x 44 and we took the whole Google docs and the menu bars with all the items, I know that Google will never add 44 between them. If your button is wide enough so you don't have to stick with your finger on the edge you also don't have a problem if there's not 8 pixel spacing in between

Detlev: could there be dynamic spacing because the larger the target is the less you need. if big but gap of three pixels it may be usable but not the same problem if you have a footnote sitting right next to a text link which are both tiny

Jake: but I guess it's much harder to test as well because of both are dependent on each other it's a harder calculation

Kim: so is testing just a few sizes our recommendation?

Marc: yes, because otherwise issues

Jake: I think if we want to have it all that it needs to be simplified in that way somehow

Kim: Note: the last comment was Detlev, not Jake

Jake: I agree with Detlev. It might be good to check with more people just to make sure it's waterproof
... but again best way forward – at least get Sean and Wilco involved because in the end this must be tested in an automated way

Kim: any other thoughts or questions we should ask Wilco or Sean

Jake: if you measure distance from the center and they are certain distance apart then you don't have to talk about the eight pixels – if the distance is more than 44, then you are fine. That could be another approach. So if the distance from the center point between two targets is 44 or bigger, if you have two 44's next to each other the distance between Centerpoint is also 44
... then you don't have to care about the eight pixel distance, just what's between

Detlev: wasn't that part of the draft text that it would apply to targets that were smaller than 44 x 44. I was under the impression that was already included

Jake: yeah and if they're smaller you need the eight
... maybe invite Wilco or Sean to a call

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: Detlev, JakeAbma, MarcJohlic, kim
Present: Detlev JakeAbma MarcJohlic kim
No ScribeNick specified.  Guessing ScribeNick: kim
Inferring Scribes: kim

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 17 Oct 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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