MATF Minutes 14 January 2016

MATF Minutes 14 January 2016 link: 
https://www.w3.org/2016/01/14-mobile-a11y-minutes.html


  Mobile Accessibility Task Force Teleconference


    14 Jan 2016

See also: IRC log <http://www.w3.org/2016/01/14-mobile-a11y-irc>


    Attendees

Present
    Kathy, Kim, Patrick_Lauke, Henny, David, Alistair, Jon, Jeanne
Regrets
    Detlev, Alan_Smith
Chair
    Kathleen_Wahlbin
Scribe
    Kim


    Contents

  * Topics <https://www.w3.org/2016/01/14-mobile-a11y-minutes.html#agenda>
     1. continue touch discussion
        <https://www.w3.org/2016/01/14-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2016/01/14-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2016/01/14-mobile-a11y-minutes.html#ResolutionSummary>

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


      continue touch discussion

<Kathy> http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation

<jeanne> http://w3c.github.io/Mobile-A11y-Extension/#touch-navigation

Kathy: there was a good discussion with Patrick on email on touch sizes, 
we're going to continue that discussion

<david_000> drop that url in again thx

Kathy: summary from discussion last week an email thread is we really 
should be going off of CSS pixels
... if you set screen to device width then DP is the same as pixels

<david_000> I'm ok with that

Kathy: the bottom line is pixels rather than points or DPs or actual 
physical size. One Apple point is one CSS pixel. One DP under Android 
also equals one CSS pixel
... if you have a conversion that says 48 x 48 pixels that makes it 
easier for everyone to understand because that equates to CSS
... anyone else have a different understanding

Jeanne: it used to be different

Kathy: the catch is display needs to be set to device width -- that's 
the differentiation

Jeanne: there's something about the real-world size of a finger that 
doesn't translate totally to pixels -- should talk to Patrick

Kathy: maybe Patrick can shed more light on this. Physical size finger 
versus calling out by pixel

Patrick: to make a really long and complex story short there's no way 
that I can guarantee any physical size on the screens when creating my 
content. That goes for Web content using pixels and for native as well
... the classic example was the iPad mini when it was introduced -- 
records the same pixel dimension, same points dimension, but is 20% 
smaller in screen size. Cry at time particularly from web developers 
doing responsive stuff -- there was no way for them to detect that 
unless user agent sniffing -- no way for them to account for that. 
That's one common example from a single...
... manufacturer....
... Once you start looking across the spectrum of devices out there 
there really isn't any kind of way that a developer can guarantee that 
anything will be rendered a particular physical size.

<jeanne> That is a good point that developers don't know the physical 
size, and I think it is unrealistic to expect developers can test every 
single device size.

Patrick: the feeling behind we want to guarantee physical size because 
of finger and we want to specify that in millimeters -- I don't think 
that's a viable way of writing an SC because there are no ways for 
developers to guarantee that. Would have to use convoluted things 
sniffing for devices, any other change any device they might not have 
access to for testing, all of a sudden the past...
... that you got during an audit turns into a fail, so this is not a 
good foundation to build in SC on

Kathy: you're right -- I agree Patrick

Patrick: the most reliable -- look at pixels and rely on device 
manufacturers to have settings
... there will be outliers here and there but generally for most common 
devices if you say width device manufacturer give what is understood to 
be normal and that generally works. There are variations ranging from 9 
mm on one to 12 mm on another one -- there's a range, however, choosing 
something that seems to average out to a reasonable size in the physical 
world using the most common...
... devices as at least initial guides seems to be the best approach. 
Once you start moving into native application development the names 
changed but roughly equivalent
... a native developer using Xcode may have to think how to translate 
that but in broad terms these measures all roughly equate to each other 
in ideal conditions -- that's the impression that I'm getting. Point is 
fairly equivalent to a CSS pixel when the browser is using an ideal viewport

David: when you're dealing with the retina the points are roughly 
doubled -- what does that do to the points in CSS?

<jon_avila> yes, I can concur

<jeanne> So maybe what we need here is an instruction to the browsers to 
implement ideal width correctly.

<jon_avila> On my phone this page reports 320 pixels 
https://labs.ssbbartgroup.com/index.php/Responsive

Patrick: not doubled. CSS pixels are resolution independent.When the 
iPhone came out with the retina display it still reports 320 with pixels 
however equate 640 physical pixels but as a web developer developers 
didn't have to go double numbers because once you set browser to width 
equals CSS is the same

<jon_avila> pixel ratio is indicated as 2 (window.devicePixelRatio)

Patrick: the content developer doesn't have to worry about that. 
Internally any measure that says 40 pixels regular display 40 x 40 
pixels retina display 80 x 80 pixels. As a content developer I never 
need to care or worry about what the physical pixels are, always working 
with CSS pixels

David: I'm in CSS file and I put the size -- that's what you're talking 
about wwith CSS pixels?

Patrick: yes

Alistair: another avenue to look at -- the size of the pointer that's 
actually tapping the screen
... I have a pen diameter about 8 mm, that's something you can specify

Patrick: but essentially saying the same thing -- physical size

Alistair: easy to test, complexity

Patrick: complexity is being able to test. You are saying developers 
need to guarantee that the physical rendition on any particular screen 
regardless of size

Alistair: understood. I train people to do these kind of tests, it's 
really easy to give them the ruler and do that. I understand that that 
changes depending on display size, but it's easy to test. Complex once 
we talk about pixels. Third option just specify that it's got to be able 
to be hit by a pointing device of a certain size. Not measuring 9 x 9 on 
the screen, just using pointing...
... device to simplify things -- just thinking out of the box

Kathy: a pointing device is much smaller than a finger so if we just 
said that it's possible that you couldn't just touch something and 
activate it

Alistair: you would specify a size for the pointing device -- different 
measurements on the screen, pointing device size or pixel size. I think 
we need to consider the pointing device size option

Jeanne: I think this is one of those situations where we are giving the 
developer responsibility for something that should be platform or 
browser dependent. We should focus on separating this is the 
responsibility of the user agent, this is the responsibility for the author

Patrick: I understand the issue about we need to make it simple, but it 
also needs to be testable. Depending on what device a particular 
developer or auditor has in front of them, something can pass on one and 
fail on another. Giving actual hard number if it's in a reasonable range 
at least on the most common devices what they map particular pixel sizes 
to and physical sizes, that is far...
... more testable. Also a particularly strange ideal viewport is 
responsibility of device manufacturer

David: I agree with Patrick. What Alistair is proposing is seeing it on 
the screen. We have testing and we have coding. Alistair talking about 
testing. We can make it a little bit complicated in the SC and simplify 
it in the understanding. One of the criticisms we get -- and it's really 
necessary -- you have to get it right in the SCand make the 
understandability manageable in the...
... understanding do

cument and tutorials. I'm actually not against the idea of getting CSS 
pixels. I'm a little concerned that CSS pixels be stable in the next few 
years -- is this something that could change in CSS 4? we also tend to 
shy away from specific technologies in the SC. But we have to solve it.

David: I would be for finding out if CSS is stable and if it is using that

Kathy: understanding of points and color contrast

David: understanding of color contrast as precedent

Jon: normative language is larger text

<patrick_h_lauke> if the color contrast SC talks about physical points 
on the screen, my same concerns would retrospectively apply to this too

David looking at language to see

<jeanne> +1 Patrick

<david_000> Normative description of large text

<david_000> large scale (text)

Kathy: if we go down this path, is 48 x 48 standard right now. Is that 
the correct way of looking at it?

<david_000> with at least 18 point or 14 point bold or font size that 
would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

<david_000> Note 1: Fonts with extraordinarily thin strokes or unusual 
features and characteristics that reduce the familiarity of their letter 
forms are harder to read, especially at lower contrast levels.

<david_000> Note 2: Font size is the size when the content is delivered. 
It does not include resizing that may be done by a user.

<david_000> Note 3: The actual size of the character that a user sees is 
dependent both on the author-defined size and the user's display or 
user-agent settings. For many mainstream body text fonts, 14 and 18 
point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the 
default size for body text (assuming that the body font is 100%), but 
authors would need to check this for the particular...

<david_000> ...fonts in use. When fonts are defined in relative units, 
the actual point size is calculated by the user agent for display. The 
point size should be obtained from the user agent, or calculated based 
on font metrics as the user agent does, when evaluating this success 
criterion. Users who have low vision would be responsible for choosing 
appropriate settings.

<david_000> Note 4: When using text without specifying the font size, 
the smallest font size used on major browsers for unspecified text would 
be a reasonable size to assume for the font. If a level 1 heading is 
rendered in 14pt bold or higher on major browsers, then it would be 
reasonable to assume it is large text. Relative scaling can be 
calculated from the default sizes in a similar fashion.

<david_000> Note 5: The 18 and 14 point sizes for roman texts are taken 
from the minimum size for large print (14pt) and the larger standard 
font size (18pt). For other fonts such as CJK languages, the 
"equivalent" sizes would be the minimum large print size used for those 
languages and the next larger standard large print size.

Patrick: question of how stable CSS pixels is going to be. Taking a step 
back we've been talking about not just web content but also native 
applications. If we just stick to web content itself generally a lot of 
specifications referencing CSS pixel as normative unit of measure. Touch 
events working group and pointer events working group all reference CSS 
pixels. At least from that point of...
... view I don't think it's anything volatile, CSS pixels.
... whether there might be refinements I'm not sure, but it's fairly common

<agarrison> 
http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size

Patrick: BBC guidelines 44, I've also seen 48. I would err on the side 
of slightly higher values

Alistair: dropped a link to the BBC thing -- you see a range 7 to 10 mm 
or about 44. Less prescriptive to give a range
... flogging that other people are reasonably uncertain about giving a 
pixel by pixel number but give a range

<patrick_h_lauke> but if we're defining a minimum, why give a range? 
just use the lowest number and say that's the minimum?

Henny: always keep in mind that BBC guidelines are for BBC content, but 
made public.

Kathy: your recommendation about a range for this guideline?

<jon_avila> To david: Note 3: The actual size of the character that a 
user sees is dependent both on the author-defined size and the user's 
display or user-agent settings. For many mainstream body text fonts, 14 
and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% 
of the default size for body text (assuming that the body font is 100%), 
but authors would need to check this for the particular fonts in use. 
When fonts are defined in relative [CUT]

<patrick_h_lauke> if you say "the minimum size must be between 44 and 48 
px" it's equivalent to say "the minimum size must be 44"

Henny: not too strong in either direction -- might be more applicable if 
there was a range

David: points is from the old print industry and its 1/72 of an inch, 
it's actually an measurement on the screen. We haven't said pixels in 
WCAG we've said points. It might not be the right thing to do, but we 
have precedent to measure on the screen if we want that

Patrick: points actually anchored on the ideal pixel unit so it's not 
physical

<patrick_h_lauke> https://www.w3.org/TR/css3-values/#absolute-lengths

<jon_avila> from definition of large text: The point size should be 
obtained from the user agent, or calculated based on font metrics as the 
user agent does, when evaluating this success criterion.

Jeanne: let's not follow a bad precedent

David: I'm not saying we need to go this way -- I want to do the right 
way and I'm hearing Patrick's strong concern. Reading guideline

<patrick_h_lauke> "For print media and similar high-resolution devices, 
the anchor unit should be one of the standard physical units (inches, 
centimeters, etc). For lower-resolution devices, and devices with 
unusual viewing distances, it is recommended instead that the anchor 
unit be the pixel unit. For such devices it is recommended that the 
pixel unit refer to the whole number of device pixels that best 
approximates the reference pixel."

Jeanne: interesting definition -- I like that they put it back on the 
user agent, but I think we could give better guidance for what the user 
agent should do and then what the author should do based on the user agent

Patrick: in an ideal world insist that user agents do X. CSS at least an 
anchor
... the precedent of they don't want to break the web -- just make the 
assumption and say in the informative text that this relies on having a 
sensible ideal and leaving it at that

Jeanne: I agree with that

David: I agree -- user agent, not measure it on screen

Kathy: so setting it at a minimum of 44 x 44 pixels, is that where we 
have landed?

Patrick: we could test on a few devices just to get a rough feel at least
... unreasonably common devices and at least that gives a yardstick to 
work with

Kathy: I think that's a good idea -- maybe if we could get some data on 
that that would be great

<patrick_h_lauke> happy to test (with a ruler) on a few devices what 
44px, 46px, 48px, 50px and what that means in actual mm

Alistair: in terms of how you are picking your point, their guidelines 
44 by 44, but lots of devices 48

Kathy: like contrast, WCAG reference higher than iso

Alistair: need to back it up with data

<david_000> let's put up a test

Kathy: find research
... some from MIT and Microsoft -- needed larger touch target than the 
minimums
... need to look into it but we may find we might want to set a larger 
touch size

<Kathy> We currently have this exception: "except when the user has 
reduced the default scale of content."

David: some number around 40 -- we will do the research to get that 
exact number going forward

<Kathy> http://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer 
<http://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer>

Kathy: if we change into pixels should we still have this exception?

<patrick_h_lauke> no CSS pixel resizes with zoom

David: I don't think we want one dimension anymore

Patrick: if I understand the exception correctly my answer would be no 
-- if we are basing it on CSS pixels once the user pinch to zoom the CSS 
pixel will adapt accordingly. The measure is still accurate. There's 
nothing the author can do. We could put something in about in the 
explanation of -- 44 x 44 is a good size for an average user to tap a 
particular control provided that they did not...
... make the content smaller by zooming -- informative, but I don't 
think any exception

<patrick_h_lauke> yes at default zoom, using ideal viewport 
(width=device-width)

Alistair: from a testability angle it is good to be able to say

Kathy: we can add that to the understanding document

<Kathy> 2.5.4 Touch Target Size: Any touch target measures at least 44px 
by 44px.

Patrick: it's worth saying zoom and ideal viewport
... deal viewport -- the devices standard mapping of device width, 
certainly for Web content should make sense

Kathy: do we need that in the success criteria or something like I just 
dropped into IRC -- we can change the numbers but should we add in the 
viewport information into this success criteria

Patrick: needs to be in the normative language

<david_000> we should use the full word pixel with a link to a 
definition as CSS pixel

Kathy: ideal language?

Alistair: at a specific default viewport

Kathy: at standard viewport size

<Kathy> 2.5.4 Touch Target Size: Any touch target measures at least 44px 
by 44px at standard default viewport size.

Patrick: as a starting point this is good. Might want to look at 
normative language elsewhere

<Kathy> 2.5.4 Touch Target Size: Any touch target measures at least 44px 
by 44px at default viewport size.

David: link to definition of pixels

Patrick: CSS spec has definition

Alistair: presume 2.5.5 update with same language

Kathy: yes -- talk about touch target clearance as well and adjust 
accordingly

<patrick_h_lauke> example from pointer events spec we talk about CSS 
pixels then link to https://w3c.github.io/pointerevents/#bib-CSS21 which 
refers to css 2.1 https://www.w3.org/TR/CSS2/

Kathy: out of time, thanks Patrick for joining today. I think we've got 
the new version. If you can do the research on the sizes we can talk 
more about what exactly should be the minimum sizes from there

<patrick_h_lauke> (and in CSS 2.1 pixel is explained in 
https://www.w3.org/TR/CSS2/syndata.html#length-units) 
<https://www.w3.org/TR/CSS2/syndata.html#length-units%29>

<patrick_h_lauke> so as example in the PE spec under attributes 
https://w3c.github.io/pointerevents/#attributes-1 see how width and 
height mention "CSS pixels (see [CSS21


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/01/14 17:31:08 $

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