Re: Pixel, Points and Spatial Measures

Maybe the real  problem is solved.

I mean, if a person with 20/80 vision cannot read your site at 400%, a
person with 20/20 can't read it with 100%.

Maybe we only need to drop "point"as a term and let market pressure solve
the base font issue for us. Over the last 400 years publishers that used
font below the critical print size for fully sighted readers went broke.
That's why newspapers and books have the font size they do.

Wayne

On Fri, Jan 13, 2017 at 9:09 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> It doesn’t to me, I wouldn’t worry about it, at least for how others see
> it.
>
> When you send a text email, Gmail (and most clients) will add line breaks
> at around 70 characters, regardless of where you put breaks in.
>
> When you view a text email you have sent at a width of under 70 chars,
> you’ll get extra line breaks.
>
> For me viewing full screen, it is normal.
>
> Cheers,
>
> -Alastair
>
>
> On 13/01/2017, 16:11, "Wayne Dick" <wayneedick@gmail.com> wrote:
>
>     Question? Why does Gmail print paragraphs is funny cupets? My letters
>     always look strange.
>
>     Wayne
>
>     On Fri, Jan 13, 2017 at 8:09 AM, Wayne Dick <wayneedick@gmail.com>
> 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.
>     >
>     > 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.
>     >
>     > I can look up common platforms and compute the pixel size needed to
>     > achieve critical print size. 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.
>     >
>     > From this foundation, percentage has meaning. Without it, percentage
>     > is meaningless as an effective accommodation.
>     >
>     > I really think we should avoid the word point in our standard.
>     > 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.
>     >
>     > This problem really is solvable.
>     >
>     > Wayne
>     >
>     >
>     >
>     > On Fri, Jan 13, 2017 at 6:59 AM, Wayne Dick <wayneedick@gmail.com>
> wrote:
>     >> On Fri, Jan 13, 2017 at 6:59 AM, Wayne Dick <wayneedick@gmail.com>
> wrote:
>     >>> On Fri, Jan 13, 2017 at 1:52 AM, Alastair Campbell
>     >>> <acampbell@nomensa.com> wrote:
>     >>>> Wayne wrote:
>     >>>>> In web jargon 12pt = 16px, a flexible measure... We will
> ultimately talk to web developers in pixels because pixel is the unit of
> web measurement. I propose omitting the use of point size as a measure in
> our discussions and speak only in pixels for screens size
>     >>>>
>     >>>> That I certainly agree with, on the call last Tuesday someone
> made the mistake of saying points and meaning pixels, which are 25% off in
> terms of size. As pixels are the unit designers and devs use, they general
> mistake PT as meaning pixels anyway, which leads to mis-calculation of text
> size when doing colour contrast checks.
>     >>>>
>     >>>>
>     >>>>> what a person can see is determined by the angle it subtends on
> the retina.
>     >>>>
>     >>>> And worth noting that the CSS pixel is defined as an angle. [1]
>     >>>>
>     >>>>
>     >>>>> I propose that in font size issues for low vision we use spatial
> measures, and give conversion tables for developers. We can give our
> developers conversion tables in the techniques.  I can do it with
> centimeters and inches.
>     >>>>
>     >>>> It would be misleading to use spatial measures as the basis for
> the SC for web content. When a browser opens on a device, it decides what
> size a “CSS pixel” is.
>     >>>>
>     >>>> *Every other measurement unit is based on that CSS pixel*.
>     >>>>
>     >>>> Inches, CMs, EMs, REMs, PT, everything is based on the CSS pixel.
> (Percentages and VW/VH are based on viewport size, in CSS pixels.) The
> browser and OS convert the CSS pixels to device pixels for display (which
> is why stuff doesn’t get smaller on high-res screens, and occasionally you
> can get rounding errors).
>     >>>>
>     >>>> As I’ve said before [2,3,4] and I’ll repeat: CSS Pixels are the
> only relevant, semi-consistent measure for sizing web content across
> devices.
>     >>>>
>     >>>> As Patrick said, you could convert the other way as a rough
> guide, but we have to test in CSS pixels.
>     >>>>
>     >>>> -Alastair
>     >>>>
>     >>>>
>     >>>> 1] https://www.w3.org/TR/CSS21/syndata.html#img-pixel1
>     >>>> 2] https://alastairc.ac/2012/04/relative-pixels/
>     >>>> 3] https://alastairc.ac/2013/02/how-to-hold-your-ipad/
>     >>>> 4] https://alastairc.ac/2012/11/in-defence-of-pixels/
>     >>>>
>
>
>