MATF Minutes October 17, 2019

*MATF Minutes October 17, 2019

Link: https://www.w3.org/2019/10/17-mobile-a11y-minutes.html
*
*Text:*


  Mobile Accessibility Task Force Teleconference


    17 Oct 2019


    Attendees

Present
    Detlev, JakeAbma, MarcJohlic, kim
Regrets

Chair
    SV_MEETING_CHAIR
Scribe
    kim


    Contents

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


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

<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


    Summary of Action Items


    Summary of Resolutions




-- 
___________________________________________________

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