W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2018

Re: notes on 320 CSS Pixels to inches

From: John Foliot <john.foliot@deque.com>
Date: Thu, 18 Jan 2018 14:32:13 -0500
Message-ID: <CAKdCpxx4aRgFRQrkSgdjtcd6Wc7UZXWb3nGbRJsrMxHh1Vo_jg@mail.gmail.com>
To: "Hakkinen, Mark T" <mhakkinen@ets.org>
Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Hi Mark,

Interesting thought experiment, but I think it's also worth noting that
currently the mobile device vendors (key players in this) have all also
come forward suggesting a measurement of between 40 and 48 px square, based
upon the same basic understandings/research that "finger touch points" are
roughly 10-12 mm square. I think it is reasonable to presume that they will
continue to continue to do so, and equally support those measurements based
upon shared understanding of the finger touchpoint size.

In other words, we arrived at the number based upon what the vendors are
already "suggesting" - we're now just mandating what has already been a
Best Practice from these vendors.


On Thu, Jan 18, 2018 at 2:09 PM, Hakkinen, Mark T <mhakkinen@ets.org> wrote:

> ´╗┐On 1/18/18, 1:24 PM, "Patrick H. Lauke" <redux@splintered.co.uk> wrote:
> ...
>     This happens regardless of the size of the monitor. Meaning that there
>     is zero guarantee that "10mm" defined in CSS will actually result in
>     10mm as measured on the actual physical screen.
> I should have been clearer, I am not suggesting in any way that authors
> define size using the problematic CSS physical lengths. My question for
> this SC is: will 44 CSS Pixels result in meeting what research tells us
> should be a 10 mm (or 9 or 12) minimum physical size on any device from
> which the user is trying to select a target with their finger tip?  I
> assume the answer is no. Larger is always better, we know that. Smaller on
> the other hand?
>     Author have zero control over achieving an SC that mandates a physical
>     (as measured in real world on the screen) size. And funnily enough,
>     auditors, when testing if content passes or fails, will also not have
>     any guarantee that their test is accurate, as they will get different
>     results depending on which particular device, mobile phone, etc they
>     test on.
> So, what's the point of this SC?  Aren't we, for the user's sake,
> effectively mandating a minimum physical size? If you are trying to support
> the physical (real) dimensions of what is known from research to be an
> acceptable minimum target size but the SC requirement can't guarantee that
> it will actually produce a minimum usable target size for a user who
> requires it on their device (the audience we are serving through WCAG),
> then this SC is pointless.
>     WCAG already made this fundamental mistake (of basing something on
>     real-world measurements, since they borrowed it from the print world)
>     when defining "large scale text" for contrast. Please, let's not make
>     this same mistake again...
> Agree. Let's not make this mistake.  The only alternative I can think of
> is (quickly):  All touch targets must have role, state, and name specified
> so that assistive technologies (or user agent features) can provide
> alternative selection methods (for example, enlarge target areas).
> ________________________________
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
> Thank you for your compliance.
> ________________________________

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion
Received on Thursday, 18 January 2018 19:32:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:22 UTC