MATF Minutes September 24, 2020

*MATF Minutes September 24, 2020
*
*Link: https://www.w3.org/2020/09/24-mobile-a11y-minutes.html*
*
Full text of minutes:*


  Mobile Accessibility Task Force Teleconference


    24 Sep 2020


    Attendees

Present
    kim_patch, Jennifer, Detlev, Kathy, Chris_Meeking, Sukriti
Regrets

Chair
    SV_MEETING_CHAIR
Scribe
    kim_patch


    Contents

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


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


      touch target feedback

Kathy: lots of things that also break existing sites
... let's look at Detlev proposed

Detlev: that will probably be overlapping space as well – stacked list. 
What's the default line height in browsers? Might be good to see what 
happens if you do nothing at all just put text in a browser in several 
lines – how much space would there be?

Sukriti: 1.2, line height would come to 16 point eight, if it 16 it 
would be around 18

Detlev: would have to set the line height at 1.6

Sukriti: that would take you to 27

Detlev: that might be okay

Kathy: looking at David McDonald's reply – high impact on designers, 
high-impact on testing, benefits questionable good given easy to zoom 
browsers.

<Kathy> "The size of the target for pointer inputs, including 
non-interactive space surrounding the target not shared with other 
targets, measures at least 26 by 26 CSS pixels except when:"

Kathy: Detlev's revision proposal

<Kathy> Here is the original: Target Size (AA) The size of the target 
for pointer inputs is at least 26 by 26 CSS pixels except when: • 
Inline: The target is in a sentence or block of text; • User Agent 
Control: The size of the target is determined by the user agent and is 
not modified by the author; • Essential: A particular presentation of 
the target is essential to the information being conveyed.

Detlev: slight modification to say size of target including 
noninteractive space around the target. That would allow a list of 
contents where you have the actual target height the link is only 14 or 
16 pixels but there's enough space above and below to come up to

Chris: concerned about this thought process – user configuration setting 
that lets the content scale. I'm not aware of any reasonable application 
that would have the problems you're describing. The font at the largest 
size would always make the lists plenty high
... both Safari mobile browsers and native mobile application at the 
largest default set of applications should more than account for 26 pixels

Detlev: we're also talking about desktop scenarios
... this needs to work for both mobile and desktop

Chris: in mobile I don't see that this is a problem so why not let 
desktop people just decide

Detlev: need to do both

Chris: if this is trivially solved on mobile, our opinion is relatively 
inconsequential because this is such an inconsequential thing to solve 
for both mobile and browsers

Detlev: desktop websites – if this criterion comes to pass and is valid 
in 2.2 many sites will fail because list of contents, drop downs do not meet

Chris: I understand but let's reserve the desktop website conversation 
for the desktop folks and focus on solving the mobile side of the 
problem which is Trivially solved

Detlev: so you would have no problem dropping the success criterion

Chris: I would encourage that – at least from a mobile perspective

Kim: I think that's a good point that maybe our insight as the mobile 
task force is that it's easy to solve on mobile but not on the desktop

Kathy: for Screen reader users?

Chris: there's no risk of accidentally activating the way it works – 
touch to explore solves problems for mobile users that is more akin to 
navigational structure, where it allows faster navigation but is not a 
blocker. If we were using that evidence to support this then I would 
heavily be in favor of dropping because those users are going to solve 
those problems different ways

Detlev: can there be situations where web developers who work on 
responsive view of a website cram too many things into some navigation 
bar, for example 8 items in one line and they, the targets would get 
quite small. I think that there's nothing that would prevent them from 
doing that, so I don't know whether you could say that that problem is 
already solved by mobile

Chris: The comment there would be handled by a responsive web design 
criteria and wouldn't have to do with mobile specifically. Absolutely 
this success criteria applies to restricted web languages and those 
languages need to do the things they do to be responsive but at that 
point your website and the way the success criteria applies to the 
website is no different than shrinking your browser down to be the size 
of mobile

Detlev: if you don't shrink– rearrange things, you might have Arroyo of 
icons at the bottom or top and you could decide as a designer to make 
them quite small because you want to fit eight or Nine icons – if that 
is the case do the icons get to small to activate? That's what this 
criterion is trying to solve

Chris: interesting point – if you want to write success criteria for an 
application that literally doesn't exist across the apps Store, lots of 
things. But the second we talk about websites were talking about 
responsive design not mobile.

Detlev: this requirement make sure the targets don't get too small if 
people use responsive design

Chris: there's a distinction on mobile between the way text sizing and 
mobile and text sizing and apps happen. Safari respects those mobile 
devices for determining size. That's the way that works we don't have 
any control over that.
... so mobile and responsive are distinctly different and sizing issues 
and they need to be considered separately

Detlev: we are now considering not mobile but web design

Chris: I don't think you have enough technical understanding of the 
platform to understand my comments

Detlev: that may be the case. Are you saying that Safari can't allow you 
to have small buttons running along the screen

Sukrit

You can set mobile browser size during set up – that would solve a lot 
of problems. Users can always magnify. But we also need to have a 
baseline criteria which is what this one is trying to do

Sukriti: so I think his point was valid, users can change.

Kathy: I understand you can change the text size and increase the touch 
target. But there is a point where when they are too small you might 
make it hard to read

Sukriti: also the problematic part that we are trying to deal with is 
mobility difficulties

Kathy: yes – that's what were trying to solve. It's easy to get wrapped 
up in the rest of this
... so we are assuming that a user has low vision or is needing to 
increase that size to actually touch it if we are relying on those user 
settings

Detlev: only if it picks up the size from your settings – it would not 
work with everything – you might have tiny fonts with some in large with 
others – is that still the case

Kathy: it's always based on size if you do zoom it's all proportional. 
some may get very big if others are big enough

Detlev: some very large but other fonts would not pick that up then you 
would have to zoom in to increase the size of things. Maybe that this 
exists as a possibility is enough to leave this alone, but if there is a 
row of icons that is quite small – he seemed to imply that that was 
prevented by the operating system. I'm not sure whether that's true.

Sukriti: he was trying to say that people realistically won't do that 
and apps like that don't exist

Detlev: I've seen some apps which are pretty awful in the past

Sukriti: that was my interpretation – as possible he was trying to say 
something else
... the conversation is only around getting data around the number – as 
long as we can justify the 26 is not an arbitrary number. Detlev, was 
that your understanding as well?

Detlev: yes – there were people saying whatever number we pick it will 
be somewhat arbitrary
... there were others saying maybe it should be smaller target just to 
prevent the really bad cases

Kathy: the 26 came from really taking the 44 in half to 22 and then 
adding the four pixel spacing.
... and we started looking at guidance from Microsoft, android iOS 
perspective and looking at what other icons or touch areas have been – 
but you look at all of those and they're all different. Everybody has 
their own perspective on that. So this was really just a stake in the 
ground saying here's the research let's take all of that into account 
and then look at the actual size that we would feel is good.
... and then looking at the spacing between stacked items as well

<Kathy> Apple's iPhone Human Interface Guidelines recommends a minimum 
target size of 44 pixels wide 44 pixels tall. Microsoft's Windows Phone 
UI Design and Interaction Guide suggests a touch target size of 34px 
with a minimum touch target size of 26px.

Kim: might be good to see if you can find an example of Icons that are 
too crowded

Detlev: need web examples – look at both and desktop and mobile

Kim: if we can find something we can point to that might be useful

Kathy: Microsoft suggest 34, but minimum 26 target size
... looking at Nielsen Norman group – minimum size 1 cm x 1 cm

<Kathy> https://www.nngroup.com/articles/touch-target-size/

Kathy: anybody know of any other?

Sukriti: looking at the New York Times homepage– the stock row seems to 
be smaller, I'd have to check
... on mobile it's fine – it's smaller on desktop
... two research articles from the MIT media Lab –the research there to 
support 26 or 24

<Sukriti> http://touchlab.mit.edu/publications/2003_009.pdf

Kathy: 1 cm letter is approximately 37 pixels.

Detlev: depends on the physical resolution and how many pixels are taken 
up to make up a CSS pixel?

Kathy: yes does depend on the DPI

Sukriti: if we're trying to avoid only the really really bad cases with 
the most noncontroversial thing to do be the font size and then take the 
four pixel spacing around it?
... trying to get consensus – take the default font size and then add 
four pixels around it for the minimum size if we can't find consensus 
for the minimum size

Kathy: that would bring us to 24

Sukriti: if we were to go even lower than that we could use the one 
point two default for justification – 18, but if you have them stacked 
it's around 20. That way most would not likely fail it and we would face 
less Pushback

Detlev: it would be good to see what fails this – example of a map, but 
MAP you would zoom anyway, might not be a good example

Sukriti: that would be one of the exceptions – where it's necessary to 
have things close together

Kathy: what are the typical DPI settings?

Sukriti: all over the place with different devices

Kathy: what's the range: 38 pixels is done at 96 dpi

Sukriti: we can use android as a Reference ranges from 537 to 367

Jennifer: iOS similar – 326 to 500 DPI

Sukriti: we can take 300 to 500 range as baseline

Detlev: but then the device three Physical pixels, two physical pixels 
so you'd have to calculate that as well

Kathy: 100 dpi 118 Pixels in a centimeter

Detlev: taking up Sukriti's suggestion of just font size plus four – 
would that meet the target with Line height of one point two if that's 
the default

Kathy: were almost getting back to original one where we say Just spacing

Detlev: it might be good have a basis but then would the criteria still 
be useful at all– if there are so few samples of that ever happening. 
Very tiny font and list in that font

Sukriti: it's the really bad cases be able to avoid – most designers 
won't choose

Kathy: the other argument why we started talking about 22 pixels which 
was half of the 44 x 44 was because we have a success criteria of 
requiring 200% and therefore if we did 22 x 22 pixels it would be enough 
for the touch target size. So if we took that 16 going up to 22 means we 
have three pixels between
... around a normal one
... if you magnified your screen to 200% you're making everything bigger 
by doubling it. So if we have A touch target of 22 by 22 and you magnify 
you're up to 44 x 44

<Kathy> 
https://medium.com/@zacdicko/size-matters-accessibility-and-touch-targets-56e942adc0cc

Kathy: why size matters article – they're saying 9 mm which I believe is 
the 44
... android physical size 9 mm regardless of screen size
... recommended target size for touchscreen elements is 7-10 mm

Sukriti: research on pointer target size – W3C website devices, DPS, 
resolution

Kathy: I think that came from our original research

Kathy 106 DPI baseline density

Sukriti: I think that's closer to Kindle pixel density

Kathy: says in most cases target should be separated by 8 which is 16 pixels

Sukriti: that would bring us to 24 again
... is everyone still in favor of having success criteria – if so we can 
put the research behind it

Kathy: I think given mobility issues and just people with tremors and 
other issues I think it is important. Smaller target is going to be 
harder for them to activate controls.

Sukriti: . I can spend tomorrow and part of the Weekend looking at other 
research and coming up with options and what the rationale would be and 
send it to this group so we can pick one and send it to Alastair

Agreement

Kathy: 20 came from Alastair's comment early on and we were thinking of 
either 22 or 24 before that. So if this 26 was simply from Alastair's 
comment of the working group suggestion of 26 pixels – he put that in 
there based on other research was 24. That's just where we ended up.

Sukriti: on the guidelines working group people were happy with it as 
long as we can back it up with research – I'll spend some time doing that

Kathy: anyone against having the success criteria in there

Jennifer: think any touch target size rule that we have will be 
beneficial – AA

Detlev: there were also comments on github – we need to look at 
different scenarios different types of targets and different 
combinations in drop downs in overlays on top of other links to be clear 
that can be sold to the working group and also to the world at large.

Kathy: let's go back and forth and try to identify those edge cases and 
based on what Sukriti comes up with – I think the stacked list in the 
drop-down list are things we have to answer
... good conversation – we've taken up the whole hour – I think it would 
be good to have some stake in the ground that will make things better
... we'll end here – will look for your emails Sukriti, Hopefully by the 
weekend because he working group meets Tuesday

<scribe> *ACTION:* Sukriti to find research backing up and email tomorrow

<trackbot> Created ACTION-88 - Find research backing up and email 
tomorrow [on Sukriti Chadha - due 2020-10-01].


    Summary of Action Items

*[NEW]* *ACTION:* Sukriti to find research backing up and email tomorrow


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes manually created (not a transcript), formatted by David Booth's 
scribe.perl 
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 
(CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2020/09/24 15:58:53 $


**___________________________________________________________

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