RE: MATF Minutes September 24, 2020

Thanks Alastair.  We are putting together the research and recommendations.

Kathy
VP Enterprise Accessibility & General Manager

T (978) 443-0798  C (978) 760-0682
The Paciello Group & Interactive Accessibility
17757 US Highway 19 N, Suite 560, Clearwater, FL 33764
https://www.paciellogroup.com<https://www.paciellogroup.com/>
https://www.interactiveaccessibility.com<https://www.interactiveaccessibility.com/>

A Vispero(tm) Company
https://vispero.com/

NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, please reply to the sender indicating that fact and delete the copy you received. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Thursday, September 24, 2020 2:01 PM
To: kim@redstartsystems.com; public-mobile-a11y-tf@w3.org
Subject: RE: MATF Minutes September 24, 2020

Hi everyone,

Good to see some discussion and progress on target spacing. Just to note that we wouldn't be able to get something into the AG agenda for this Tuesday (29th), but having something for Wednesday (30th) would be idea for the meeting on the 6th Oct.

Cheers,

-Alastair


From: Kim Patch <kim@redstartsystems.com<mailto:kim@redstartsystems.com>>
Sent: 24 September 2020 17:05
To: public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>; ran@w3.org<mailto:ran@w3.org>
Subject: 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>
     *   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>
___________________________________________________