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

Re: notes on 320 CSS Pixels to inches

From: Jonathan Avila <jon.avila@levelaccess.com>
Date: Thu, 18 Jan 2018 20:37:18 +0000
To: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Message-ID: <7BE184F8-3FBB-432F-B8A5-12D1C0DD0C8C@levelaccess.com>

We should consider that zooming in and our may be difficult for the group of people who need larger targets. 

Jon

Sent from my iPhone

> On Jan 18, 2018, at 2:50 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
>> On 18/01/2018 19:09, Hakkinen, Mark T wrote:
>> [...]
>> 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?
> 
> In most cases, it results in a size that is, generally, near enough that particular physical size in most devices/OSs.
> 
>> So, what's the point of this SC?  Aren't we, for the user's sake, effectively mandating a minimum physical size?
> 
> It's mandating a minimum CSS size which, in most cases, on most devices, gets close to a good physical size - give or take a certain degree of uncertainty.
> 
> As the uncertainty can't be magicked away, it's the next best thing that can be mandated.
> 
> If, instead, an SC mandated an actual physical size, it would make it impossible for authors to guarantee they're meeting the SC on all possible past, current and future devices/user agents. Ditto for testing. And if a new device came out which, for whatever reason, decided to have a different logical viewport dimension / CSS px to real-world physical measurement ratio, it wouldn't retrospectively make a pass now fail when tested on that device.
> 
>> 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).
> 
> role/state/values would already fall under 4.1.2.
> 
> Not all users that require large-enough targets (note this isn't just touch, but also mouse) run AT.
> 
> (But as noted, in the worst case users can zoom (as long as it's not suppressed) to make targets, and all other content, larger).
> 
> -- 
> Patrick H. Lauke
> 
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
Received on Thursday, 18 January 2018 20:37:44 UTC

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