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

read the definition in the Glossary 

it explains it there

gregg

> On Apr 26, 2016, at 2:49 AM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> 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
>