Issues with print stylesheet

[thomasgohard]

The following issues have been raised in https://github.com/wet-boew/wet-boew/issues/5718:

• The Government of Canada signature is enlarged while printing and overlaps the Canada wordmark.
• The font size is larger.
• The Government of Canada links (Canada.ca, Services, Depts, language toggle) are being printed.
• The breadcrumbs are being printed.
• <abbr> elements are expanded when printed.
• Link URLs are being printed.

Adding to those:

• The icon for the mobile menu is being printed.

[thomasgohard]

@Tradewagon @gdanova did I summarise the issues correctly? Anything to add or that I missed?

[gdanova]

Yes, that summarises it all. I didn’t even bring up the issue of the mobile menu icon being on the printout, but thanks for adding it.

[thomasgohard]

Government of Canada signature: The problem occurs because no height is specified for the image in the CSS. Adding a height fixes this. I'll have a pull request with that fix shortly.

Font size: @zachfalsetto and I are looking at typography issues. I'll make sure that print typography is considered as part of that.

That being said, I think the print font size is probably fine as it is. 16px is equivalent to the standard 12pt used in print. And the current line length in print (going by the print preview in Firefox) is around 95 characters per line on average. That's above the generally recommended 45–75 characters per line from traditional typography. But it matches the recommendation for 95 characters per line from this readability study.

Government of Canada links: Those indeed should not appear in print. I'll have a pull request with that fix shortly.

Breadcrumbs: I don't know whether those are useful in print. I have no data on that.

Printing the breadcrumb shouldn't hurt anything as it can be easily skipped. We can also reduce the amount of space used by not printing the URLs for the links in the breadcrumbs. Someone can easily navigate back to the site version of the printed document from the breadcrumb without having the URLs. It's probably quicker too than trying to type in the URL. I'll have a pull request with that fix shortly.

<abbr> elements: Abbreviations should be avoided altogether; the only exceptions are when the acronym is better known than the long form, or when the acronym is universally known.

But when acronyms are used, the long form should be available where each acronym is used in the text. Otherwise, you're forcing the reader to find where an acronym's long form was made available which breaks the reading flow.

The article Abbreviations: accessibility for web writers, part 14 is a great summary of why you should avoid using acronyms.

Link URLs: This has been raised in a few other issues recently so I won't deal with it here. The main issue for dealing with this issue is https://github.com/wet-boew/wet-boew/issues/4229.

Icon for mobile menu: It shouldn't appear in print. I'll have a pull request with that fix shortly.

[gdanova]

Government of Canada signature: That would be perfect.

Font size: Seems acceptable.

Government of Canada links: That would be perfect.

Breadcrumbs: Removing the URLs would be a good compromise. I'd even suggest a smaller font size just for that, if possible, as it would prevent some of the wrapping.

ABBR: I read the article. Interesting in theory, but you can't eliminate every acronym (especially in the GC). As for the long form being available where each acronym is used, I must disagree. That's why the <abbr> tag is useful. Online, it avoids expanding the text, which would reduce readability. In print, the convention for years has been to expand on first usage only precisely because doing so on every occurrence would reduce readability. If you don't set to expand with the Print stylesheet, the output wold become formatted as intended for print, i.e. expand first occurrence.

Icon for mobile menu: OK.

[thomasgohard]

It is entirely possible to eliminate every acronym: always use the long form. The article I linked to above also offers other strategies.

Acronyms are what reduce readability, not the long form. Acronyms force the reader to either remember what the acronym stands for or look up the meaning of the acronym. Forcing the reader to remember something that could be made available on the interface violates the "recognition rather than recall" usability heuristic. Remembering something is also slower than reading it. And looking up the meaning breaks the reader's flow, increasing the time needed to read and reducing comprehension. This is true both online and in print.

It's not because printing the long form of an acronym upon first use is common that it's usable. Printing the long form upon first use makes assumptions that are simply not true.

First, it assumes that the reader reads the entire page from start to finish. This isn't true, especially online: Readers scan.

Second, it assumes that the reader will remember the acronym as they read the page. Again, that's not true. People don't automatically remember something after being exposed to it once, memory is more complex than that. Frequency of exposure, recency of exposure and context all affect memory. Also, if a page has multiple acronyms in the same text, then there's multiple acronyms to learn and remember. This increases the complexity of reading and comprehending the text.

It also assumes that the reader will not be distracted or interrupted while they read the page. Distraction and interruptions affect your ability to remember something. And distraction and interruptions are a common occurence:

Office workers are interrupted—or self-interrupt—roughly every three minutes, academic studies have found, with numerous distractions coming in both digital and human forms.

source

Acronyms are author-centric, not reader-centric. They allow the author to write more quickly, at the cost of readability for the reader. People use acronyms as shortcuts for things they deal with on a regular basis. But you can't assume that your reader uses them regularly as well.

Also, on mobile devices, the user cannot access the long form as the long form is only available by hovering over an <abbr> element. Hover functionality does not exist on mobile devices.

[gdanova]

Not sure what the purple "Merged" indicator means (2 messages up), or if it's related to a "pull request" but is a fix available for download?

[LaurentGoderre]

@gdanova it means that a pull request related to this was merged in

[gdanova]

And does that mean that a fix is now available?

[thomasgohard]

@gdanova yes. Once a pull request is merged in the fix is available at least in the development version.