Re: Changing definition of "Large text" to use px rather than pt

On 26/04/2016 01:42, Gregg Vanderheiden wrote:
> Notes are NOT normative.
> You are correct
>
> but in definitions…  hmmmm..
>
> pts are defined in inches — so they are an absolute number.
>
> pixels are not — or do you have some absolute definition of px meaning a
> fraction of an inch (or mm)?

Gregg, are you seriously suggesting that WCAG 2.0 actually meant "14pt 
bold / 18pt" *as measured on the screen with a ruler* all along? Rather 
than CSS "pt", which are by definition 1.333px (see 
http://codepen.io/patrickhlauke/pen/zqabMR) ?

What did the actual testing procedure for "large text" look like then? 
"Open the page on your browser, take a ruler, and measure the size of 
the text as rendered on the screen"?

If you *are* meaning that WCAG 2.0 meant actual physical sizes all 
along, then...I'm sorry, but we're back to the problem that it is 
impossible for an author to actually guarantee at what physical size 
anything is rendered on every user's screen. So the normative language 
for WCAG 2.0 includes a requirement that cannot be absolutely tested, as 
it depends on each individual user's physical screen size, resolution, 
zoom factor, dpi, etc.

Or are there any techniques that you can point to on how an author can 
guarantee, on every device, in every browser, that something will render 
at a particular size? I'd love to see them - but suspect they do not 
exist, as this is an impossibility, since it varies so heavily across 
devices. Is WCAG 2.0 requiring a magic pony?

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 Tuesday, 26 April 2016 07:49:29 UTC