Mobile Accessibility Task Force Teleconference -- 14 Jan 2016

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

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)

<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

- DRAFT -

Mobile Accessibility Task Force Teleconference

14 Jan 2016

Attendees

Contents

continue touch discussion

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output