-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.4.8: Visual Presentation - line spacing (leading) clarification #2256
Comments
Depending on the answer to this, there might need to be a small note/clarification in the understanding (particularly around what default spacing for the font, as the anchor for the other 1.5x calculation, actually means in practice), and possibly a technique with the live example code. |
My understanding is that the default spacing of a font is not related to the determination of what space and a half line spacing means. We have a technique (CSS21) that shows that line-spacing: 150% on paragraph text is sufficient as this is 1.5x line-spacing:100% - as you point out, the default for a given font might be to have a line-height that is some value other than 100%. If you choose a font with a default line height of 1.5/150% or more then this SC can be tested just by looking at the page. I do think that the "(the default spacing for the font)" is confusing and we should remove that. |
probably worth then also rewriting the understanding bit to be more specific / relating it to the font-size ( |
@patrickhlauke I don't think that 1em works because the 1em measurement is the height of the capital M but the baseline to baseline measurement represents the line-height and that varies by font also. |
so it wouldn't necessarily be a default "line height" in the CSS sense, but just the way the font metrics shake out? it would be reported as having so probably best to talk more specifically about cap height or similar (to borrow the graph from wikipedia here) ...and then leaving it as an exercise for the reader to work out, maybe even a bit subjectively/eyeballing it, if the leading is 0.5 the cap height |
ok, but we need to ideally anchor this somewhere. baseline to baseline must be 1.5 times the em height, i.e. leading must be 0.5 of the em height? keeping in mind also that as everything can be variable (depending on how the font was constructed/how accurate its reported metrics were), it may make sense to handwave it and say outright that our assumption is that (again thinking here of some kind of note that hints at the wooliness that can potentially happen, and advises authors to explicitly set the line height themselves rather than relying on whatever the UA decides is the default) |
i guess in the end, simply removing |
looking over https://www.w3.org/TR/CSS2/visudet.html#line-height
so perhaps the fudge/simple way to sidestep all my circular thoughts about
|
ok, made a fairly boiled-down PR #2262 that should ideally correct/clarify this (Without getting into all the weeds above about what user agents do by default if you don't specify a line height in CSS etc) |
some more discussion/thoughts on the PR comments, but I think a rather fundamental aspect (copying this back over here):
|
Currently, in the examples for the understanding, it shows this which seems to be (though i may well be wrong, as just eyeballing it) an example of a line height of about a space and a half (or just slightly over?), not an example of leading set to space and a half for comparison, a screenshot of my live codepen https://codepen.io/patrickhlauke/pen/oNoKrdw |
The answer here may even be that because as i've seen folks take the idea that |
probably worth discussing a bit further here, rather than being ready for a survey... |
further language oddity (in the understanding document) that is worth somehow ironing out in all this:
versus (emphasis mine)
150% further means 250%. it's either "50% further", or that the distance is "150% (of the original value)" |
This SC is unfortunately not well conceived, as noted, the defined leading of a font, and relative to the font's x-height, varies per font family, as does tracking and kerning (letter spacing). Therefore, setting a guideline based on an abstracted value is less than ideal. What would be ideal is to define spacing based on the x-height. Also, this SC does not allow for or give credit to the use of an indent or combination indent + vertical space Paragraph spacingAs for using line-height for spacing in between paragraphs, that is inappropriate. Line-height should only be set for the full block of text, trying to use a The best way, as far as consistency is:
All that said
But that is also too tight. A good line-height is 1.33 to 1.45, depending on the font ( Whatever the line-height is, divide it in half, and that is the
|
For best readability line-height increases with the number of characters per line. This helps with tracking as people read. Headlines at a large font size also have fewer characters per line, therefore tracking is less of a problem and a line height closer to Edit: here is some additional context: https://tbrown.org/notes/2012/02/03/molten-leading-or-fluid-line-height/ Here is a quick demo: https://codepen.io/scottkellum/pen/rNvXJaO |
dredging this topic up again ... any more thoughts on this? I know it's not urgent, but would be good to see if there's any more clarity that can be brought to the understanding document |
Hi Patrick @patrickhlauke, For writing systems with mixed case, the line height for body text should be relative to the x-height. Glyph characteristics and the font design/font metrics are still a consideration, as is the average text line length in a column of body-text, and that column's padding, etc., all play a role. As Scott pointed out above, other use cases such as headings/headlines may work better with different leadings. All this makes a reasonable, normative guideline more challenging. If we introduce use-cases (APCA Readability Criterion: Use Cases), then we can offer better guidance. At a minimum:
Click to expand on density & use-case."Text density" is the next generally applicable consideration, this being the total number of characters in a given container area, including padding. Smaller text has a higher density and therefore needs more leading. Large headings have a lower density and need less leading. Longer line lengths need more leading than shorter lines (as in number of characters). A column with an average of 35 characters per line needs less leading than block widths with an average of 80 characters per line. This theory probably extends to condensed fonts needing more leading than expanded fonts, and thin weight fonts needing more than bold fonts. The actual impact on readability for these glyph characteristics vs leading is not well defined in existing literature that I've seen. Use-case could be a useful way to indicate "text density" for guideline purposes. For instance, we could say that:
^^^^^^^^^^^^^^^^ ex marks the spotThe line-height property, when unit-less, is based on p {line-height: 3ex} Here, the line-height is set to three times the x-height. A typical font will have it's built-in leading at 2.25 times the x-height. For web content, 2.25ex is probably insufficient for body text, but fine for headings. 2.75ex to 3ex is probably a better minimum line-height: for body text. ex-amplesI have a page full of font size and spacing examples for many different fonts. The leading using |
to be clear: this clarification here needs to be within the context of the (unchangeable) normative wording of the SC. this is not about finding better guidelines/advice, but clarifying what we're working with right now to provide clarity on what was originally meant. we're not workshopping better normative guidelines. |
Understood, my point being that the current SC is somewhat meaningless relative to the technology as it exists or lacking in evidentiary support, for the reasons I and others have stated in this thread.
For that your initial query answers itself:
This says specifically that it should be 150% of the default baseline-to-baseline distance per the default leading, which is usually about 1.1em to 1.25em, or thereabouts, and varies per font. CSS does not provide a metric other than "normal" that references the font's built in leading, i.e. the "default spacing"(sic) for the font. Therefore a polyfill would be needed to first determine the font's default leading, etc. On this point, other advice such as at Mozilla is to set https://developer.mozilla.org/en-US/docs/Web/CSS/line-height But the "original intent" of the SC might most simply be addressed with Setting line-height to 1.8 is effectively similar to the "original intent" of the SC. The SC could clarify with: "for many fonts, this can be achieved by setting Bigger ConfusionA bigger confusion though is the next line in the SC Understanding, which reads:
IMO that jumble is challenging to grok. If p {
font-size: 1em;
line-height: 1.8;
padding-bottom: 1.7em
}
p:last-child {
padding-bottom: 0.5em
} This CSS block clarifies the intent to all, with no ambiguity, and with the bonus that it is using the available technology as it exists. An alternate for p {
font-size: 1em;
line-height: 1.5;
padding-bottom: 1.25em
}
p:last-child {
padding-bottom: 0.5em
}
Well, I am And I would submit that as an open standards organization, publicly viewable objections to existing standards, or suggestions of improved best practices, or the realities of science and math, should not be obstructed, suppressed, or censored, just because they don't align with existing beliefs. Thank you for reading. |
We can discuss how things should be improved in the next version of the specification ... in a separate thread. On a thread about tweaking the documentation for the current standard (which can't be normatively changed), it's really not that helpful. There are many aspects in WCAG 2.x which are flawed or outright broken. But that is the spec that is currently referenced by requirements and legislations, so we have to work within those confines. We've been over this already in the contrast ratio discussions... |
One of the points of 1.4.8 Visual Presentation states:
In the understanding document https://w3c.github.io/wcag/understanding/visual-presentation.html it expands this further to
Now, in CSS, the closest property to influence the spacing of lines is
line-height
. Line height is the height of the font itself, plus the leading (half-leading at the top and bottom).The default spacing for the font, when you just don't touch
line-height
, or have it set toline-height: normal
, will vary for each font - it will be whatever the user agent deems to be the ideal default line-height (top and bottom half-leading) based on the font metrics (supposedly anyway - see https://www.w3.org/TR/css-inline-3/#line-height-property which is still in draft).Anecdotally, from some testing, for the standard Times New Roman in Windows (at least on my machine), Chrome makes
line-height: normal
about equivalent toline-height: 1.14
. So, when 1.4.8 asks for 150% further space, does this mean that for that particular font, an author must define a minimumline-height: 1.71
(1.14 * 1.5 = 1.71
)? And for each font used, must authors first try and guess what the actualline-height: normal
equates to, to be able to then do the 150% of it?This would further be complicated by the fact that authors cannot guarantee which exact font will be used on a user's machine in the end - with font substitutions, possibility that a web font won't load, etc (and even differences in metrics across different versions/cuts of the same font with nominally the same name).
Or, for simplicity and consistency, are we treating
line-height: 1
to be the default spacing for the font, meaning that to pass this an author must define a minimum ofline-height: 1.5
? (I've seen this interpretation being used on a few AAA audits, anyway)This latter interpretation would also gel with what I've seen in a few of the "text-spacing bookmarklets" for testing 1.4.12 Text spacing https://w3c.github.io/wcag/understanding/text-spacing - these generally set
line-height: 1.5
.If this is indeed the case, the example pictures in https://w3c.github.io/wcag/understanding/visual-presentation probably could do with being amended, as they seem to not use
line-height: 1
as their basis, but rather use whatever theline-height: auto
is, and then eyeballed (?) the space and a half and double space based on that actual rendered size (as aline-height: 1
would be slightly tighter in the left-most example, andline-height: 1.5
andline-height: 2
would also be slightly tighter together)Made a live example in codepen https://codepen.io/patrickhlauke/pen/oNoKrdw using
line-height: normal
and then the exactline-height: 1
/line-height: 1.5
/line-height: 2
. It's subtle, but I think it is ever so slightly tighter than the example image in 1.4.8 - and you should be able to see the subtle difference betweenline-height: normal
andline-height: 1
(and this will vary by actual font defined/used).The text was updated successfully, but these errors were encountered: