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

On 26/04/2016 09:28, Alastair Campbell wrote:

> ‘Large text’ is in the glossary, which is labelled as normative.
>
> Note 3 within the definition indicates that the measure is based on
> the user-agents calculation, not a physical size: "The point size
> should be obtained from the user agent, or calculated based on font
> metrics as the user agent does, when evaluating this success
> criterion.”
>
> I think there are two useful steps from here:

I would like to see at least the "The point size should be obtained from 
the user agent, or calculated based on font metrics as the user agent 
does, when evaluating this success criterion." part of note 3 be made 
FAR more prominent. As it stands, this buries the lede. That one nugget 
of information should be prominently made Note 1. I'd say this is an 
editorial change, not a substantive change, so can be made even on 
normative text.

This should at least clarify the confusion (present even on this very 
thread) that these "pt" sizes are NOT meant as actual physical point 
sizes as measured on screen, but as an objective value that can be 
consistently queried from the UA.

> 1. In the near future, use the ‘understanding’ doc to explicitly say
> that 1pt = 1.33px, so use 18/24px. I have been confused by the use of
> PT before (assuming it was equivalent to px), as have many (probably
> most?) people I’ve talked to.

Is it not possible to add a note (which is informative/non-normative) to 
the definition of "large scale (text)" at least to spell out how in most 
scenarios, 14pt =~ 18.5px and 18pt =~ 24px, and make that Note 2. this 
would not change the meaning, so again an editorial rather than 
substantive change (particularly if couched in terms like "usually / 
generally / etc".

> 2. For WCAG.next, drop the explicit sizes and work from the
> user-agents' default text-size.

Yes. Based on the understanding that between user agent, OS, user 
settings, etc the base font size is "good/comfortable/large enough", 
define large as a proportion of that.

> I maintain that pixels are the best relative unit[1], as the device
> maker / browser has to decide the base size for a CSS pixel based on
> intended usage [2], which they do already quite effectively.

Indeed.

> Being aware that authors can over-ride the ‘base’ text-size by
> setting it on the HTML/Body elements, we could refer to proportions
> of the default size, e.g. 120% & 150% of the default text-size of the
> user-agent (although that might ban setting a size on HTML/body
> elements in practice?).

If large scale text is defined clearly as 120%/150% of *default* base 
font size, then authors are free to resize on html/body, but when 
calculating the actual dimensions of a piece of content to determine if 
it counts as large scale or not, they'd have to refer back to 
unadulterated/default base font size.

Whether or not the size of "normal" (non-large) text is changed or not, 
and whether that's too small, is orthogonal to this particular 
discussion, and something that should be taken on as a new SC by Low 
Vision TF (who, in my mind, should simply advise not to make text 
smaller than the default base font size, i.e. don't scale text below 
1rem on default sizes)

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 08:53:19 UTC