Re: Pixel, Points and Spatial Measures

On 13/01/2017 16:09, Wayne Dick wrote:
> If this problem was easy, it would have been solved. There is a lot we
> can do to bridge the gap between web size and spacial size. We are
> making guidelines and giving techniques.

You can't make guidelines that require something that is technically 
impossible to achieve accurately, no matter how much you'd like it to.

> The mean critical print size for text on  paper and computer has been
> calculated. Web developers will want to use this because people won't
> read there site if they deviate to much from that value. That is a
> well established fact. It is generally about .347cm on paper and
> .416cm for computer screens. We recommend in techniques that
> developers use the pixel equivalent these for their base  font... And
> we give them tables to calculate these values.

Paper is fixed and absolute size. Screens (in their various physical 
sizes and resolutions) aren't.

> I can look up common platforms and compute the pixel size needed to
> achieve critical print size.

That will only guarantee results for those particular screen 
sizes/resolutions that you tested. For fun, have a look at 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Summary_of_Research_on_Touch/Pointer_Target_Size#Comparison_of_web_content_sized_in_px_and_physical_size_of_rendered_content_on_common_device_screens 
which I did as part of the work in the mobile accessibility TF when 
touch target sizes were being discussed. This compares the actual 
rendering of what 45 CSS pixels look like in various mobile, laptop and 
desktop screens. note how the actual physical rendering size of 45px as 
measured on screen goes from 7mm to 13mm, depending on display/device 
type. So, whatever size you mandate in pixels, will potentially vary by 
a factor of 2 or more on different devices. These sorts of results can 
help inform a rough lower end value, but again there's no guarantee that 
on another device not tested there the measurement would not fall below 
that real-world measurement - and as authors have no way of checking 
that/knowing that, they may fail in real world terms while actually 
following a value that was suggested.

> We then put it in a bunch of tables as
> guidelines for platform types with guidance on how to use them. Once
> we have spread sheets with the proper formulas, mostly trigonometric,
> we can update our tables to match common platforms in use with
> technique updates. Will it be perfect, no. Will it be better than what
> we do. Yes a lot.

Sure, as I noted, guidelines can give a size of text in CSS pixels, and 
then justify that by explaining that on the majority of common current 
screen size/resolution scenarios, that will equate to something 
approximating whatever physical rendering size you're aiming for. And 
that's fine. What I do object strongly to is for guidelines to mandate 
that developers need to guarantee a particular physical rendering 
(spatial) size, as that's simply outside of their direct control, and 
not testable with any measure of confidence.

> I really think we should avoid the word point in our standard.

Oh, absolutely, and that was my point ages ago on this list when trying 
to get the "large text" definition changed to remove mention of points.

> Developers are not the only professional users of WCAG.  Disability
> lawyers don't think of point as being .75 pixels, and imprecise
> measurements will not help medical arguments in court.
>
> Patrick, we are introducing new accessibility methods. LVTF was very
> careful to identify bedrock needs. They are no more disruptive than
> the original 2.0 methods were, but they will require developers to
> think about other factors. Some of them will be difficult just like
> programmatic determinism was difficult.

There's "difficult", and then there's "impossible for authors to follow 
or for testers to test". I'm simply saying that we all need to be very 
clear what we can and can't mandate. If we mandate "must be at least X 
pixels" and then qualify that by explaining that in most common tested 
scenarios currently, that shakes out to Y mm, then cool. If the plan is 
to mandate "must be at least Y mm", then that's what I strongly object to.

> This problem really is solvable.

P
-- 
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 Friday, 13 January 2017 16:27:22 UTC