"Large text" - using px rather than pt as unit

[patrickhlauke]

Something that's been bugging me for a while...

For on-screen/web content, px would be a far more natural unit of measure than pt.

pt is (generally anyway) derived simply from the reference pixel (where then 1pt ~= 1.333px - see https://drafts.csswg.org/css-values/#absolute-lengths).

having "large text" (https://www.w3.org/TR/WCAG20/#larger-scaledef) defined in pt adds an extra layer of confusion for authors who would normally not actually use this unit of measurement in their CSS/HTML, and then may get very confused about whether or not this refers to actual physical pt as measured on the screen (which is something authors have no control over, as it will vary depending on computer/mobile phone/tablet, the OS, the browser, user settings, etc), and whether or not they need to take into account potential variances in dpi (again, not something they have any control over directly).

In short, suggest - in an update/errata to WCAG 2.0 - adding a note about the fact that this refers to CSS pt which are anchored on the reference px (which then further makes the assumption that the OS/browser/user has a reasonably close mapping of 1px to the idealised reference pixel as per the spec), or simply...using px instead (replacing 18pt with 24px, 14pt with 18.5px, etc)

At a stretch, at least complementing 18pt with the equivalent 24px - (e.g. "18pt (24px) ...")

/cc @yatil

[WayneEDick]

The point is a physical measure. There is some disagreement on how much of an inch is occupied by a point. I use the Adobe definition that is 1/72 inch. The key is it is not relative. It is a size in inches.

That is the real problem with the pixel. Pixels cannot be used to measure font-size from the point of view of accessibility because the same measure 24px can be from 16 point to 22 point depending on the dpi. 16 point really isn't large print.

The user does not care how many pixels it takes to make their critical print size, they just want that size because it facilitates reading. For example, to become readable at a 3:1 ratio rather than 4.5:1 requires a physical size in points, inches or centimeters.

I do agree that the point may be a bad measure because its definition is not set. The inch or centimeter would be better.

[patrickhlauke]

The point is a physical measure. There is some disagreement on how much of an inch is occupied by a point. I use the Adobe definition that is 1/72 inch. The key is it is not relative. It is a size in inches.

sorry wayne, but that's not (currently, and for the past few years) correct when talking about web content. from the spec

For a CSS device, these dimensions are anchored either

(i) by relating the physical units to their physical measurements, or
(ii) by relating the pixel unit to the reference pixel.

I am not aware of any devices which actually relate any of the physical units (pt, mm, cm etc) that can be used in CSS to actual physical size as measured on screen. All common devices I've tested base their calculation of physical units by referencing its relationship to whatever their 1px size is.

The user does not care how many pixels it takes...

That may well be, but as a developer has NO actual control over the actual physical size at which, say, a definition of 18pt is actually rendered (as it depends on a myriad of factors, all outside of the control of the developer), this sentiment cannot be used when defining normative guidelines that developers have to follow.

[patrickhlauke]

That is the real problem with the pixel. Pixels cannot be used to measure font-size from the point of view of accessibility because the same measure 24px can be from 16 point to 22 point depending on the dpi. 16 point really isn't large print.

The problem with using pt, cm, mm etc on the other hand is that their actual physical rendering varies between devices, screen resolutions/dpi, screen dimensions, user settings, browser and OS settings, but many people still assume they actually relate to the real physical size as measured on screen. They don't.

Create a webpage, set some container or element to, say, "40pt" width and height, or "2cm" or whatever, then take a ruler out and measure it on a variety of devices - iPad Pro, iPad Mini, a 30" desktop screen set to 1920x1080, etc. You'll find a huge range of actual physical sizes that these supposedly fixed physical units actually render at (and that's on default settings; once a user actively changes, say, their browser zoom, all bets are off...and these "physical" units are zoomed just the same as everything else, as their actual size is based on...the reference pixel, which changes when zooming).

This would results in a situation where a developer is being asked/mandated to base a pass/fail of an SC on something that can vary depending on the device they're testing on. And even assuming a developer or auditor has a wide range of devices available and can make a pass/fail evaluation that covers many scenarios, all it takes is for somebody to come along with a device that the original developer/auditor didn't check and come up with a different pass/fail result...which would be ridiculous.

As an aside, this is the same reason why, say, color contrast is measured based on the values indicated in the CSS, rather than saying that it needs to be measured "on screen" with a colorimeter or similar, as again this would make an objective evaluation impossible since monitors/screens will vary in their color rendition based on hardware, color profile, browser, OS, etc.

[patrickhlauke]

I guess when this aspect of WCAG 2.0 was originally hashed out, there was still an (optimistic) assumption that browsers/OSs/devices would map pt etc to actual physical pt. And indeed previous versions of CSS still had this assumption. However, the reality is that the physical units in CSS don't match their actual physical units in the real world (as in most cases, this would require browsers/OSs to take into account physical size of the screen, which they currently don't and in many cases can't). See also the note in https://drafts.csswg.org/css-values/#absolute-lengths

Note: This definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.)

[patrickhlauke]

See http://codepen.io/patrickhlauke/full/zqabMR/ for a quick demonstration of this - comparing blocks set in pt and px

[ZoeBijl]

As far as I know, all OS' and user agents translate pt's into a fixed px value. It would thus make sense to just give the information in px. That is what a lot of people do anyway, they take the pt and simply replace the t with an x and test against that; which is wrong. This leads to the spec causing harm because it is unclear or at the very least misunderstood.

It would make far more sense to give the font size in px than in pt, even in an age where we try to get everybody to use em's.

[yatil]

That’s actually a hard one to change in general:

WCAG is (or at least tries to be) technology independent. Therefor, I guess pt as mentioned in WCAG is actually meant to be the physical size. There even is a note in large scale (text) glossary that says (quote):

Note 3: 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. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. 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. Users who have low vision would be responsible for choosing appropriate settings.

but authors would need to check this for the particular fonts in use
concerns me especially, as it implies testing all the devices with the used fonts with an actual ruler to make sure they meet the definition. Which would be ridiculous :-)

Nowadays the definition should probably be more specific, at least for CSS use, as we have both the Browser font size and the relationship of ´pt´ to pixels defined. Also we should use the “modern” units to ease development:

In CSS, 14pt equals 18.66px or 1.166rem. 18pt equals 24px or 1.5rem.

(I think it would be good to have that as a CSS technique somewhere, but I wonder where it would fit.)

[yatil]

More info on CSS units: http://www.w3.org/Style/Examples/007/units.en.html by @bert-github, which explicitly says that the pt, cm, mm, in, pc are not recommended for screen use.

[StommePoes]

The number of times the question appears in forums and mailing lists everywhere, every year: "what size is 'large text' according to WCAG?"

It would be great if it were possible to tell people a real answer. Most of us just make up px equivalents and go from there, as an exercise in practicality... which means, if we wanted to write unit/functional tests for a11y, we can't really do that for this particular part, when it should be programmatically testable in, say, Selenium.

[patrickhlauke]

More info on CSS units: http://www.w3.org/Style/Examples/007/units.en.html by @bert-github

note that https://drafts.csswg.org/css-values/#absolute-lengths clarifies/supercedes the definition that this was based on.

This definition of the pixel unit and the physical units differs from previous versions of CSS

[ZoeBijl]

@yatil

(I think it would be good to have that as a CSS technique somewhere, but I wonder where it would fit.)

Two possible places, the first note on Understanding SC 1.4.3 and the definition of “large text”.

[patrickhlauke]

For further context, see also when I raised this same issue back in 2014 https://lists.w3.org/Archives/Public/w3c-wai-ig/2014OctDec/0002.html

A key part of that discussion, to me, was Gregg's answer here https://lists.w3.org/Archives/Public/w3c-wai-ig/2014OctDec/0003.html

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.

and https://lists.w3.org/Archives/Public/w3c-wai-ig/2014OctDec/0005.html

18/14 point values are based on the fact that the user has a screen/resolution/zoom/viewing distance that makes 1em readable.

Those point sizes are ONLY used in WCAG to determine when contrast can be reduced. The assumption is that the text is readable at normal size (due to the screen/resolution/zoom/viewing distance that the user has set) and this is just saying that text that is LARGER can have a lower contrast.

and https://lists.w3.org/Archives/Public/w3c-wai-ig/2014OctDec/0007.html

The comparison should be against a page with no font size specified. That is, the “Base font” should be no font size specified.

which all, long story short, actually make me think that the normative definition of "Large text" should be modified to actually mention all these additional qualifiers (and it should not just be relegated to "we'll fix it in 'Understanding...' or similar").

@yatil

WCAG is (or at least tries to be) technology independent. Therefor, I guess pt as mentioned in WCAG is actually meant to be the physical size.

The problem with that is that regardless of technology (HTML/CSS, Flash, PDF, native apps) there is currently no way in any of these to actually define physical "real-world" sizes consistently in a way that is actually guaranteed across devices/browsers/OSs/etc.

Therefore, I'd actually move to change the normative definition of large text to essentially say something more akin to (based on roughly what Gregg said in the 2014 discussion on list)

Large scale (text)
text which is at least 1.2 times the size of the base font and bold, or 1.5 times the size of the base font

then moving the note about the "actual size" as rendered on an end user's device right after that (and modify its wording to then use px as example measurements rather than pt)

[yatil]

@MichielBijl
I meant a “real” CSS technique, like “CSS3122: Color contrast” under 1.4.3 https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=143#visual-audio-contrast-contrast – But yes, the understanding is the obvious place for such a clarification.

[patrickhlauke]

and yes, I agree with @StommePoes and @MichielBijl ... the fact that this discussion/question keeps popping up (and the length of explanation always necessary, even for people like myself who have been working on the web and on accessibility for aeons) is evidence to me that there's something fundamentally borked with the current wording in the normative part of WCAG

[yatil]

(Furthermore, back in the day when 16px was humongous, many people basically defined 14pt = 14px and 18pt = 18px, which made some sense as their – chosen – base font was often 10px.)

[alastc]

I agree, the place it really needs change is in the definition:
https://www.w3.org/TR/WCAG20/#larger-scaledef

For years I assumed pt=px, so was underestimating the size of large text.

@yatil Note 3 in the large scale text definition is meaningless, it is trying to compare pt, em & %, when they are all based on (CSS) px.

A challenge to the group: What device that can show web-content does not base it's sizing of PT on CSS pixels?

[patrickhlauke]

and as an aside, just to muddle the water: once authors start to look at WCAG in the context of native (mobile) app development, there's further confusion about what a pt means. Apple uses pt in their iOS guidelines, but it's not a pt in the physical real-world sense, but a shorthand for Apple's own device/density-independent measurement. Android uses device/density independent pixels dps. Windows development uses effective pixels (again, a device/density independent pixel). It all just gets very confusing (particularly with Apple's reappropriation of the points term to mean once again something slightly different from actual physical pt)

[patrickhlauke]

@alastc

A challenge to the group: What device that can show web-content does not base it's sizing on CSS pixels?

My money's on "none, or if they do, it's by accident/chance" (using my own http://codepen.io/patrickhlauke/full/zqabMR/ I found that my specific monitor - a 23" Dell at 1920x1080, with Windows running at 1920x1080 as well - actually rendered 72pt in CSS close enough to a real-world 1in as measured on screen...but then when I open the exact same thing on my laptop, the measurement is off by a considerable amount, not to mention when you then open it on an iPhone 6s or similar, where 72pt is closer to 0.5in as measured on screen)

Which is part of my point (hah, no pun intended): as for an author there is no way to actually set anything in CSS and guarantee that it will consistently be presented to a particular physical real-world size, having normative text that actually specifies real-world physical sizes is like asking developers to come up with a magic unicorn technique...

[ZoeBijl]

Problem there is that it's silly to specify a value and unit without viewer distance to screen. We live in a world where we a legion of different devices, all of which we hold at different distances from our face. My laptop is generally closer to my face than my iMac. My iPhone even more so. I get that there is need for pt as a unit for print etc. There should, however, be an equivalent for the web in px.

[patrickhlauke]

Problem there is that it's silly to specify a value and unit without viewer distance to screen.

The assumption has to also be made that the base font size is that which the device/OS/browser/etc manufacturer has deemed to be appropriate for their device, based on their device's typical viewing distance. But yes, this is fundamentally another variable which makes physical "real-world" size even more ambiguous. Using px (under the assumption above that a device is using its "ideal viewport" http://patrickhlauke.github.io/web-tv/ideal-viewport/ / http://www.quirksmode.org/mobile/metaviewport/) at least removes any further ambiguity, I'd say.

[MakotoUeki]

Which is part of my point (hah, no pun intended): as for an author there is no way to actually set anything in CSS and guarantee that it will consistently be presented to a particular physical real-world size, having normative text that actually specifies real-world physical sizes is like asking developers to come up with a magic unicorn technique...

+1

Steve also pointed out this issue at:
https://www.paciellogroup.com/blog/2012/05/whats-large-text-in-wcag-2-0-parlance/

[cheshrkat]

All the options are imperfect... but of all the imperfect options, I would prefer to see this information using px than pt (or list px as well assuming the basic conversion metioned earlier in the thread). It's just easier to understand and more likely to result in action.

[alastc]

I edited the definition to see how easy it was. I think it was fairly straightforward (although obviously it would have to be a change to normative text).

large scale (text)
with at least 24 or 19 pixel (px) bold, or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

Note 3: 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. For many mainstream body text fonts, 19px and 24px is equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 16px), but authors would need to check this for the particular fonts in use. The pixel size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.

Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 19px bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.

Note 5: For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.

[jnurthen]

This edit would lead to any code which was written to use 14pt bold to no longer be classified as large text. This cannot happen. What was large text before any change must remain large text after any change.

On Apr 21, 2016, at 07:13, Alastair Campbell notifications@github.com wrote:

I edited the definition to see how easy it was. I think it was fairly straightforward (although obviously it would have to be a change to normative text).

large scale (text)
with at least 24 or 19 pixel (px) bold, or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

Note 3: 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. For many mainstream body text fonts, 19px and 24px is equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 16px), but authors would need to check this for the particular fonts in use. The pixel size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.

Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 19px bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.

Note 5: For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.

―
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[alastc]

How so? 14pt = 19px.
You might have just confirmed the mis-assumption that many people make (including me for many years!)

[ZoeBijl]

@jnurthen this wouldn't change anything. It would just clarify what 14pt bold actually is. 14pt bold is not the same as 14px bold.

[patrickhlauke]

@alastc

I edited the definition to see how easy it was. I think it was fairly straightforward

I'd actually keep it even more high-level at first, as per my proposed amendment

Large scale (text)
text which is at least 1.2 times the size of the base font and bold, or 1.5 times the size of the base font

and then perhaps add something - a note? - about "for instance, with a base font size of 16px - the common size in most current browsers - this would translate to 19px bold / 24px" or similar

[jnurthen]

14pt = 18.666px
Not 19px. If I define my font as 14pt then I no longer meet this new definition but I did before.

On Apr 21, 2016, at 07:23, Alastair Campbell notifications@github.com wrote:

How so? 14pt = 19px.

―
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[patrickhlauke]

14pt = 18.666px

round it down then to the nearest half pixel, I'd say, for sanity. call it 18.5px. but that's a tiny detail in the larger scheme, I'd say (unless we want to argue the tiny fractional values)

[ZoeBijl]

@jnurthen 18.666px does not exist, you can't have fragmented CSS pixels. With the possible exception of half CSS pixels on 2x density screens.

[dstorey]

Something that shows pt being mapped to logical CSS pixels in CSS is if you compare the size of PTs in an app vs a web browser. In this case Word (100% zoom / actual size). There is a huge difference, which is one of the things that leads to designer/dev confusion when moving from mocks to implementation

Also our Microsoft data (1,218,301 unique URLs crawled using Edge and Chrome) clearly shows that PX is way more widely used: https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/font-size/

PT is used less than Ems and %. Also bear in mind that this includes all rules that applies, so I believe print styles will be picked up here. It also doesn't show how much more a unit is used on a site, just if it is used once or not. I suspect on the sites where both are used, PX is used in a lot more declarations.

[patrickhlauke]

Proposed changes to at least the notes part of the glossary definition: #184

[awkawk]

@patrickhlauke The pull request for this changes the core WCAG 2.0 document. Do you want to suggest changes to the understanding document or do you want to mark this with the WCAG next label and close it until we are ready to consider that?

[patrickhlauke]

@awkawk so to be clear: can nothing in WCAG 2.0 be changed (anymore), not even informative/non-normative notes? Is this not essentially an editorial clarification?

i believe having this shuffled off to understanding may not work out (particularly if in future other SCs may crop up that do need to refer to the definition of what "large scale (text)" is - which would then need this to be duplicated/triplicated in each relevant SC's understanding)

If all else fails, then I guess the only option would be WCAG next...

[awkawk]

I don't think that this is editorial. If you would like to ask the group we can, but I'd rather focus our energies on the wag next path.

[patrickhlauke]

I would like to ask the group one time directly if this can be considered editorial, thus ok for inclusion in WCAG 2.0 - maybe as part of a survey? After that, if the group does not see it as editorial, happy (of sorts) to slate this for the next path.

[mraccess77]

IMO the lessening of the contrast requirement should be in relationship to size of the default font and shouldn't really be specified in pt or px. I agree that it's no guarantee it's readable and many people with low vision need larger fonts and that if you go larger it doesn't mean the need for contrast goes away. I believe the goal of the criteria was to lessen the level of contrast for text that was 1.2x bold or 1.5 the size. Since many sites are now using mobile we can't really assume 12pt/16px as default font size and using this is problematic. These units should only be examples to the requirement which is measured by 1.2x bold or 1.5 the default font size.

[alastc]

@mraccess77 That is pretty much what the explanation says and directs people to do, more clearly than the original text (IMHO).

The first question is whether we can change the notes under the definition (is it editorial or substantive), which is on the survey. Then we can get onto the exact wording.

[mraccess77]

@alastc Yes, just lending my support to the push for change. Regarding whether it can be changed or not -- while I think we could change a note in a definition section I don't think we can change the definition part that is not preceded by a note. But this is not my area to comment on.

[alastc]

In this case it would change almost all of the 'notes' under the definition, which are fairly lengthy (5 or 6 paragraphs), but not the definition itself.

[patrickhlauke]

Since many sites are now using mobile we can't really assume 12pt/16px as default font size and using this is problematic

even on mobile, the default font size is 16 CSS px on most common devices. how big those CSS px actually appear will then depend on various factors, including whether or not the site was set to use an ideal viewport of width=device-width and whether the user has zoomed in/out...but those are factors that we can't take into account (nor detect), so they are irrelevant (for the context of color contrast, not readability)

[yatil]

Just for consideration: Making the distinction between large and small text by setting a relationship is useful with normal-sized text but gets ridiculous when someone is using a large base text size (like 25px). Should they be not allowed to use the 3:1 ratio? I think in the future we need to find another measurement for this – or get rid of the exception altogether.

[patrickhlauke]

btw, for clarity...as i see a few comments flying in on this - would be good to get feedback on the actual hard proposal here #184 (which spawned from this discussion and the discussion on list)

[joshueoconnor]

@patrickhlauke Thanks for your work on this - very interesting. The consensus was that we will not incorporate the suggested changes into WCAG 2.0 but work on updating the Understanding document and consider this issue flagged for the WCAG 2.1 release. You can follow the discussion in the minutes.[1]

[1] http://www.w3.org/2016/05/17-wai-wcag-minutes.html

[patrickhlauke]

@joshueoconnor and which "Understanding" would that be exactly? as this is in the general definitions, and not in a particular SC's prose, it doesn't naturally belong in any particular understanding doc (though in practice that definition IS only referenced by the color contrast SC)

[patrickhlauke]

if this is being deferred to next, i think it would actually make matters a lot clearer (as the situation around differing device sizes, zoom levels, viewports, etc is only bound to become MORE confusing, rather than less, in future) to seriously consider what @yatil mentions...

or get rid of the exception altogether

Set a single contrast ratio, no exceptions. (this would then avoid the potentially subjective assessment not only of sizes, but also "how bold is bold?", "what about this particular font i'm using which is unusually think/thick/has a small x-height" etc)

[alastc]

I've created an update to the contrast understanding doc (visual-audio-contrast7.xml seems to match the live version):
dbaf3d0?diff=split

But I'm struggling to work out how to create a separate pull request from the previous one, when I start that process it seems to combine it on top of the previous one, is that ok?

[alastc]

With a little git-foo I've created a new branch and got a pull request for updating two understanding docs:
#188

[patrickhlauke]

Closing this, as per discussion/advice on process for these deferred items.