Re: Clarification on normative glossary definition of "Large scale (text)"

The WCAG definition covers the issues quite well.  The issues raised in these various posts was considered in creating the SC and the definitions. 

The goal is to have text be larger than typical font.    The size that a font appears to the user is dependent on lots of things - like zoom of browser, pixel density of the display, scaling (some displays like the retina) do not render a pixel as one pixel on the display, viewing distance, etc — all of which are outside of the control of the author — so it is meaningless to have an accessibility guideline for web authors that requires that the user see the font in a particular size, or angle subtended.     

So the guidelines were written to talk about minimum RELATIVE size of the font.   If the font is relatively larger — and the user does not use a screen resolution that is too dense — it all works out.    If the user with low vision looks at the content from a distance,  or with a high screen pixel density / screen resolution,  then the author cannot be responsible.     There is an implied contract here — that authors do x part and users do y.   Authors cannot do it all and WCAG doesn’t imply they should.    For example,  Authors do not have to make their content accessible to people who are blind.  They only have to make their content be exposed in a way that a user could use as screen reader to make it accessible to them.   Similarly, for low vision the goal it to put it within reach.  For some - just making it 1.5x font size is sufficient.  For others they may need to zoom the text. 

Regards.  

Gregg


it is defined elsewhere 
On Oct 6, 2014, at 5:57 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:

> Currently, "Large scale (text)" is defined as a measure point sizes.
> 
> "at least 18 point or 14 point bold"
> http://www.w3.org/TR/WCAG20/#larger-scaledef
> 
> Note 3 does aknowledge that "The actual size of the character that a user sees is dependent both on the author-defined size and the user's display or user-agent settings" and suggests that "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".
> 
> However, to me this does not take into account the fact that "pt" as a measure is anchored (in practically all environments, with the exception of, I believe, KDE and Konqueror) on the the measure of one CSS pixel http://www.w3.org/TR/css3-values/#absolute-lengths, which means that 1pt in CSS does not necessarily match 1pt in the traditional physical measurement sense. Further, this does not seem to take into account differences in viewing distance, or the fact that browsers/OSs/devices may not actually be using a measure that's close to the ideal viewport's *reference pixel*. This can be even further complicated on mobile/tablet devices depending on whether or not a page has been given a meta viewport directive.
> 
> In short, a measure of "18 point" can mean almost anything (even before a user may have  changed browser settings or actively used some form of zoom/resizing) depending on browser, OS, device. Does the definition require some modification or expansion? Should it, for instance, explicitly state that it's talking about CSS pt measures and, referring to the CSS 3 values spec, point out that it assumes that 1 CSS px matches the ideal *reference pixel* and that the user is reading at the average assumed viewing distance for that particular device? (which would still leave some room for interpretation, and would make any attempt at calculating the *real* pt value of any text measurement quite convoluted)
> 
> Or should the definition just drop the use of point measurements altogether, as even if those were actually meaningful in all environments, they would need to be taken as only informative measures since they're dependent on font shape/metrics anyway?
> 
> P
> p.s.: this rumination brought on by this thread on WebAIM http://webaim.org/discussion/mail_message?id=26656
> -- 
> 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, 7 October 2014 02:48:39 UTC