W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

10 Oct 2019

Attendees

Present
Kim_Patch, JakeAbma, Kathy, Jennifer
Regrets
Chair
Kathleen_Wahlbin
Scribe
Kim_Patch

Contents


https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit

touch target

Kathy: Google has a way of testing spacing between the different touch target so I suggest that maybe we go to Sean see if Google will share that with us
... Alistir said Sean said they had a way of testing it

Jake: I was discussing this at TPAC, he indicated something different – he said it's possible to tested but not that they have something already to test

<Jennifer> sorry, my computer is having problems, I'll have to try joining the meeting again

Jake: Wilco said the same thing. For every interactive element indicate position on screen. Based on that you can calculate if there is a disk<eight pixels between different components. Sean did not really impression that they already have something for that ar
... we need a script for that or a plug-in. It would be good to have that before we publish 2.2
... there is a little trick because you can calculate a button but maybe the touch target is made bigger by a custom element placed to make the button bigger than the touch target itself – make sure that that one is calculated
... but technically that should be possible
... let's ask Sean I'm pretty sure he did not mention that they had it, just that it's possible

Kathy: could you follow-up and see if they have something they can share?

<scribe> ACTION: Jake to follow-up with Sean to ask if they have something or information they can share, ask Wilco as well

<trackbot> Created ACTION-77 - Follow-up with sean to ask if they have something or information they can share, ask wilco as well [on Jake Abma - due 2019-10-17].

Kathy: testing aside, it seems like there may not be something existing right now but we can read something. I agree be good to have that before 2.2 comes out – we want an easy way to test it
... I did go through and look – Amazon uses 8 pixels of spacing, which is actually fairly tiny. Most sites 9, 10. I think 8 pixels is kind of a reasonable spacing, and based on research that helps in being able to avoid touching multiple

Jake: what's the issue of making the touch target larger instead of the eight pixels

Kathy: the trouble with that is that is in at AAA – were trying to get this in AA
... getting the pixels between the elements is easier than saying you have to have a minimum size for the touch target. That's the reasoning

Jake: I also thought of another one – first of all, you never touch target the same time. another answer is if you have two pixels of spacing between, let's say your error area will be not as big

Kathy: wrong target might activate the one you intended
... that was the main thing we need to figure out this – it seemed like on the result that the questions were around visible gaps versus just extending the size of the target. The other reason is the AA versus AAA. But I think overall there was not a lot of objections that I saw to this other than that same comment.
... so I think what we can do is follow up with Wilco and Shawn and just finalize the document and add to the testing, description of how this SC can be tested
... Jake, it might be good for you to add had that detailed conversation about calculating the position on the page and be in the elements it might be good to actually change this in the description of how this can be tested, adding that

Jake: issue: in theory every small move or change of your viewport may cause flex books to readjust itself
... and also with percentages, if you use purely percentages your spacing will change based on the viewpoint with. And also for every breakpoint
... so you would have to do that 180 times – it may be so that we have to provide some fixed width for testing

Kathy: even if we did fixed width we are still helping the end-users because you are saying there is a point in time where you could get sufficient spacing between the elements

Jake: so for the automated testing what will you test? 320, 1280, all the breakpoints, every section in between

Kathy: I think we can do 1024 and where we have the reflow where you go to 320 pixels I think we pick and say were going to do those two breakpoints. Then you're looking at a desktop version, the mobile version, and if you're on a tablet you can magnify the screen to get to the other breakpoints overall
... I'm just throwing out ideas – I think were getting ahead of ourselves. let's see what they come back with as far as implementing this as a test and see with the limitations are and then we can come back to this
... I think we can go with that I think we need to collect information first. I think it would be good if we take a look at a few more examples of notation. We do have some pretty big ones Amazon and several of the other bigger sites
... in addition to implementation details we will need to come up with some techniques.
... Jake, you had mentioned you guys do something with flex box. Is that a technique we can add to this SC?

Jake: if you have containers, just elements in your HTML and use flex box, and you put your interactive elements directly in a flex box, you just never know if you have eight pixels
... maybe the best technique is for each flex box container padding of work pixels because it doesn't matter how big the flex box becomes, you have at least four for each so you have a pixels between

Kathy: that's a good idea – if you can add that in as a technique that would be good

Jake: you can use them of course for percentages of flex box but in general just make sure that every container you place elements and has at least four pixels padding, same container, also interesting listbox items options and they are in a drop-down menu and they are not 44 pixels high may be issue

Kathy: I took a look at that – but we should look at that again

Jake: if they're not 44 pixels high and you have spacing in between them they will probably not be accepted by a lot of companies

Kathy: there's no requirement with the size of a touch target with that the only thing is if it's less than that you have eight axles between adjacent targets
... when I looked at lists of links those that have a minimum of a generally on website
... if the target is less than 44 x 44 pixels, then there's a minimum of eight pixels of spacing between adjacent targets except when the target is a block of text, so excluding a block of links or if the presentation is essential to the information being conveyed – so two exceptions
... drop-down menus, I didn't find a lot of examples where they didn't. Amazon was eight, nine was others

Jake: not sure about left menu

Kathy: we should go back and look

Jake: Amazon from Germany left menu, main menu, padding is two pixels and it's not 44 by 44

Kathy: US site, padding top and padding bottom, adds up to more than eight

Jake: hamburger menu on the left

Kathy: same – padding bottom of two pixels and padding top of seven pixels on the menu items. Other stuff going on in there but if you look at the actual padding it's more than a pixels

Jake: but not for the touch target because the touch target is the anchor element that's 42 not 44 and then only padding of two pixels

Kathy: padding top and padding bottom adding together – you're getting them on the one below and the one above, so nine pixels in between

Jake: only two pixels in between, not nine

Kathy: padding top of seven, unordered list margin 18 below

need to get the calculator out and figure out – it's more than a

Jake: I'm just telling the distance between where you can click between, for instance Amazon music and Echo Alexa, the spacing between the two targets is two pixels

Kathy: visually there's more than two pixels

Jake: I mean the pointer – distance between the touch target is two pixels. Then they just have to make bigger touch targets
... if you don't have 44 or eight, with your finger, it will start blinking between touch target it starts flickering
... there's a visual effect – a lot of designers don't want that
... on the other side there's something really good. For these kinds of menus 44 otherwise it doesn't look good because of the blinking
... most web developers have zero spacing in between those submenus – every iOS or android device you open they don't have spacing in between those kind of menus
... we still need to think about those – I know we even had them in dialogues and the bottom buttons – never spacing in between. That's a decision you have to make no eight pixels, no problem, go to 44. Just need to be aware that all these submenus – I think at least 80% have zero spacing in between and they do not all have the 44 pixels.
... I'm now at eBay. It pixels between, but the default select does not
... Adobe doesn't have space between, but they are at least 44
... Adobe is at 54

Kathy: the next step is to see if we can create a calculator for this, otherwise the validity of the SC goes down as far as able to prove that we can have an implementation and its testable
... let's get an answer or get someone to code something that and then we can make a couple of these changes to the text and we can go back to the working group with it
... let's take that as next steps

Summary of Action Items

[NEW] ACTION: Jake to follow-up with Sean to ask if they have something or information they can share, ask Wilco as well
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/10/10 15:44:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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: Kim_Patch, JakeAbma, Kathy, Jennifer
Present: Kim_Patch JakeAbma Kathy Jennifer
No ScribeNick specified.  Guessing ScribeNick: Kim_Patch
Inferring Scribes: Kim_Patch
Found Date: 10 Oct 2019
People with action items: jake

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


[End of scribe.perl diagnostic output]