Re: MATF Minutes September 24, 2020

@patrick: The naivety is in assuming that the Desktop and the Mobile
conversation are the same discussion. Different users, different input
mechanisms, etc. These conversations must be had separately in order for
them to be comprehensible.

On Thu, Sep 24, 2020 at 1:46 PM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> A reminder that a device's DPI does not necessarily have any influence
> on the physical dimensions (as measured on screen) of particular CSS
> pixel sizes. DPI measures the density of physical hardware pixels. These
> are distinct from what the OS/software consider a CSS pixel.
>
> This is, among other things, the reason why on an sites didn't suddently
> have to make a separate version of everything when the first
> high-dpi/retina displays for mobile came out ... they had much higher
> DPI, but then adapted their "how many actual hardware pixels make up a
> CSS/density independent pixel" conversion rate.
>
> However, there is, as discussed for the target size AAA SC for 2.1
> already, no consistent measure of "X CSS pixels result in this
> particular size as measured on screen", as that is completely dependent
> on the actual physical screen size, and whatever the vendor/OS has
> decided that physical size maps to in terms of width/height in device
> independent pixels.
>
> tl;dr: statements around "this particular CSS size is approximately 9mm"
> are flawed and usually wrong.
>
> As an aside, I'd also point out again that while yes, this TF is the
> "mobile" one, simply saying "we're just concentrating on mobile, let
> somebody else worry about desktop" is...naive, since the SC is by its
> very nature scoped to web content in general (on mobile, tablet,
> desktop, laptop, ...) and to pointers (touch, mouse, stylus).
>
> P
>
> On 24/09/2020 17:05, Kim Patch wrote:
> > *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/
> > <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
> > <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
> > <
> 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>
> > ___________________________________________________
>
>
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> --
> Inclusive Design 24 (#id24) https://inclusivedesign24.org
>
>