15:51:36 RRSAgent has joined #mobile-a11y 15:51:36 logging to http://www.w3.org/2016/01/14-mobile-a11y-irc 15:51:38 RRSAgent, make logs public 15:51:38 Zakim has joined #mobile-a11y 15:51:40 Zakim, this will be WAI_MATF 15:51:40 I do not see a conference matching that name scheduled within the next hour, trackbot 15:51:41 Meeting: Mobile Accessibility Task Force Teleconference 15:51:41 Date: 14 January 2016 15:51:48 chair: Kathleen_Wahlbin 15:57:43 agenda+ Review understanding document 15:57:44 agenda+ Review assignments http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments 15:57:46 agenda+ Continue to Review draft of Mobile Accessibility Extension, (touch size email discussion https://lists.w3.org/Archives/Public)/public-mobile-a11y-tf/2016Jan/thread.html) 15:57:47 agenda+ Next steps – next meeting January 21 15:59:17 regrets+ Detlev, Alan_Smith 16:02:14 agarrison has joined #mobile-a11y 16:03:00 Kathy has joined #mobile-a11y 16:05:24 Henny has joined #mobile-a11y 16:07:38 present+ 16:07:40 Topic: continue touch discussion 16:07:45 present +Kathy 16:07:56 present + 16:07:57 jeanne has joined #mobile-a11y 16:08:35 http://kwahlbin.github.io/Mobile-A11y-Extension/#touch-navigation 16:08:55 jon_avila has joined #mobile-a11y 16:08:59 http://w3c.github.io/Mobile-A11y-Extension/#touch-navigation 16:10:03 Kathy: there was a good discussion with Patrick on email on touch sizes, we're going to continue that discussion 16:10:04 david_000 has joined #mobile-a11y 16:10:15 drop that url in again thx 16:10:21 present + 16:10:30 Kathy: summary from discussion last week an email thread is we really should be going off of CSS pixels 16:10:49 Kathy: if you set screen to device width then DP is the same as pixels 16:11:12 I'm ok with that 16:11:46 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 16:12:03 Kathy: if you have a conversion that says 48 x 48 pixels that makes it easier for everyone to understand because that equates to CSS 16:12:18 Kathy: anyone else have a different understanding 16:12:38 Jeanne: it used to be different 16:13:09 Kathy: the catch is display needs to be set to device width – that's the differentiation 16:13:55 Jeanne: there's something about the real-world size of a finger that doesn't translate totally to pixels – should talk to Patrick 16:14:34 Kathy: maybe Patrick can shed more light on this. Physical size finger versus calling out by pixel 16:15:06 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 16:16:29 Patrick: 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... 16:16:30 ...manufacturer.... 16:16:32 ...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. 16:16:32 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 singe device size. 16:17:13 s/singe/single 16:17:38 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... 16:17:40 ...that you got during an audit turns into a fail, so this is not a good foundation to build in SC on 16:17:46 Kathy: you're right – I agree Patrick 16:18:07 q+ 16:18:15 Patrick: the most reliable – look at pixels and rely on device manufacturers to have settings 16:18:56 q+ to ask about app development 16:19:49 Patrick: 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... 16:19:50 ...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 16:20:14 q- 16:20:25 Patrick: 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 16:20:38 q? 16:21:10 David: when you're dealing with the retina the points are roughly doubled – what does that do to the points in CSS? 16:21:49 yes, I can concur 16:21:52 So maybe what we need here is an instruction to the browsers to implement ideal width correctly. 16:22:12 On my phone this page reports 320 pixels https://labs.ssbbartgroup.com/index.php/Responsive 16:22:17 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 16:22:53 pixel ratio is indicated as 2 (window.devicePixelRatio) 16:23:06 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 16:23:24 q+ 16:23:32 David: I'm in CSS file and I put the size – that's what you're talking about wwith CSS pixels? 16:23:38 Patrick: yes 16:23:56 Alistair: another avenue to look at – the size of the pointer that's actually tapping the screen 16:24:23 Alistair: I have a pen diameter about 8 mm, that's something you can specify 16:24:29 Patrick: but essentially saying the same thing – physical size 16:24:55 Alistair: easy to test, complexity 16:24:59 q? 16:25:06 ack agarrison 16:25:35 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 16:26:47 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... 16:26:48 ...device to simplify things – just thinking out of the box 16:27:02 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 16:27:21 q+ 16:27:26 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 16:28:43 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 16:30:17 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... 16:30:18 ack jea 16:30:19 ...more testable. Also a particularly strange ideal viewport is responsibility of device manufacturer 16:30:22 ack da 16:30:50 q- 16:31:54 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... 16:31:56 ...understanding do 16:31:57 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. 16:32:12 David: I would be for finding out if CSS is stable and if it is using that 16:32:36 patrick_h_lauke has joined #mobile-a11y 16:32:36 Kathy: understanding of points and color contrast 16:32:56 David: understanding of color contrast as precedent 16:33:15 Jon: normative language is larger text 16:33:23 if the color contrast SC talks about physical points on the screen, my same concerns would retrospectively apply to this too 16:33:35 David looking at language to see 16:33:43 +1 Patrick 16:33:58 Normative description of large text 16:34:01 Q+ 16:34:06 large scale (text) 16:34:07 Kathy: if we go down this path, is 48 x 48 standard right now. Is that the correct way of looking at it? 16:34:07 with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts 16:34:09 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. 16:34:10 Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user. 16:34:12 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... 16:34:13 ...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. 16:34:15 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. 16:34:16 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. 16:35:58 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... 16:35:59 ...view I don't think it's anything volatile, CSS pixels. 16:36:11 Patrick: whether there might be refinements I'm not sure, but it's fairly common 16:36:17 q+ 16:36:38 http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size 16:37:04 q? 16:37:11 Q- 16:37:16 Patrick: BBC guidelines 44, I've also seen 48. I would err on the side of slightly higher values 16:38:11 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 16:38:42 Alistair: flogging that other people are reasonably uncertain about giving a pixel by pixel number but give a range 16:39:24 q- 16:39:38 but if we're defining a minimum, why give a range? just use the lowest number and say that's the minimum? 16:39:46 Henny: always keep in mind that BBC guidelines are for BBC content, but made public. 16:39:57 Kathy: your recommendation about a range for this guideline? 16:39:57 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] 16:40:01 if you say "the minimum size must be between 44 and 48 px" it's equivalent to say "the minimum size must be 44" 16:40:09 Henny: not too strong in either direction – might be more applicable if there was a range 16:41:10 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 16:41:24 Patrick: points actually anchored on the ideal pixel unit so it's not physical 16:41:25 https://www.w3.org/TR/css3-values/#absolute-lengths 16:41:34 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. 16:41:41 Jeanne: let's not follow a bad precedent 16:42:35 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 16:42:40 "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." 16:43:32 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 16:46:15 q? 16:46:17 q+ 16:46:18 Patrick: in an ideal world insist that user agents do X. CSS at least an anchor 16:47:01 Patrick: 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 16:47:36 Jeanne: I agree with that 16:48:06 David: I agree – user agent, not measure it on screen 16:48:24 Kathy: so setting it at a minimum of 44 x 44 pixels, is that where we have landed? 16:49:23 q+ 16:49:26 Patrick: we could test on a few devices just to get a rough feel at least 16:49:38 Patrick: unreasonably common devices and at least that gives a yardstick to work with 16:49:49 Kathy: I think that's a good idea – maybe if we could get some data on that that would be great 16:50:37 happy to test (with a ruler) on a few devices what 44px, 46px, 48px, 50px and what that means in actual mm 16:50:54 Alistair: in terms of how you are picking your point, their guidelines 44 by 44, but lots of devices 48 16:51:52 Kathy: like contrast, WCAG reference higher than iso 16:52:01 Alistair: need to back it up with data 16:52:36 let's put up a test 16:53:07 Kathy: find research 16:53:47 Kathy: some from MIT and Microsoft – needed larger touch target than the minimums 16:53:59 Kathy: need to look into it but we may find we might want to set a larger touch size 16:54:11 We currently have this exception: "except when the user has reduced the default scale of content." 16:54:13 David: some number around 40 – we will do the research to get that exact number going forward 16:54:49 http://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer 16:54:53 Kathy: if we change into pixels should we still have this exception? 16:55:07 no CSS pixel resizes with zoom 16:55:31 David: I don't think we want one dimension anymore 16:56:52 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... 16:56:54 ...make the content smaller by zooming – informative, but I don't think any exception 16:57:25 yes at default zoom, using ideal viewport (width=device-width) 16:57:35 Alistair: from a testability angle it is good to be able to say 16:57:41 Kathy: we can add that to the understanding document 16:58:17 2.5.4 Touch Target Size: Any touch target measures at least 44px by 44px. 16:58:20 Patrick: it's worth saying zoom and ideal viewport 16:58:59 Patrick: deal viewport – the devices standard mapping of device width, certainly for Web content should make sense 16:59:23 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 16:59:32 Patrick: needs to be in the normative language 16:59:44 we should use the full word pixel with a link to a definition as CSS pixel 16:59:46 Kathy: ideal language? 17:00:09 Alistair: at a specific default viewport 17:00:18 Kathy: at standard viewport size 17:00:18 2.5.4 Touch Target Size: Any touch target measures at least 44px by 44px at standard default viewport size. 17:00:42 Patrick: as a starting point this is good. Might want to look at normative language elsewhere 17:00:43 2.5.4 Touch Target Size: Any touch target measures at least 44px by 44px at default viewport size. 17:01:12 David: link to definition of pixels 17:01:27 Patrick: CSS spec has definition 17:01:40 Alistair: presume 2.5.5 update with same language 17:02:00 Kathy: yes – talk about touch target clearance as well and adjust accordingly 17:03:00 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/ 17:03:01 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 17:04:29 (and in CSS 2.1 pixel is explained in https://www.w3.org/TR/CSS2/syndata.html#length-units) 17:05:31 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 17:05:47 patrick_h_lauke has left #mobile-a11y 17:06:33 patrick_h_lauke has joined #mobile-a11y 17:07:05 patrick_h_lauke has left #mobile-a11y 17:07:06 patrick_h_lauke has joined #mobile-a11y 17:07:08 patrick_h_lauke has left #mobile-a11y 17:28:36 rrsagent, make minutes 17:28:36 I have made the request to generate http://www.w3.org/2016/01/14-mobile-a11y-minutes.html Kim 17:30:58 present+ Kim, Patrick_Lauke, Henny, David, Alistair, Jon, Jeanne 17:31:03 rrsagent, make minutes 17:31:03 I have made the request to generate http://www.w3.org/2016/01/14-mobile-a11y-minutes.html Kim 17:36:16 rrsagent, bye 17:36:16 I see no action items