I had a few questions. First, is there any possibility of a failure based on the font substitution between the printer and the screen? Same goes for a screen layout that exceeds the printable size of the paper. At some point the printer is going to have to modify the precise view of the user to fit things to a standard page. Some language around this not being a failure would be helpful.
Second, what happens in the situation where a user agent does not offer this print ability? Does the burden fall on the author? As an example, when I tried to print a magnified page in Chrome, the print version was not magnified.
Third, (and very related to the second point) on some mobile device, I'm not familiar with an ability to have the print function respond to a zoomed page, since the page is not 'reflowed' by the browser, but merely scaled up. What happens in this situation?

Happy to pick this one up too as SC Manager

I don't know technically how a developer would do this? I don't see any techniques on this... I guess we are requiring the site to support client side custom CSS style sheet substitution, and then the new Style sheet added to the browser on the client side would direct the printer on the changes it forced into the client's browser? Is that what we are requiring?

This success criteria is currently met with common HTML and browsers.

I'd echo David's question...what are we actually expecting then? Is this more an SC aimed at user agents / native applications? Is there a common failure situation that we could at least document where a page/user agent/whatever fails?

It is uncomfortable or painful for some people to be in the physical position required for reading on a computer monitor, for example, some people with low vision need to be an inch away from the display. While some people have mobile devices, others have only a monitor that is difficult to move, or use a public terminal.

For both this and the one below

Some people print so they can block out surrounding text; for example, they slide a sheet of paper down as they read to cover up the line below where they are reading. Some people need colored overlays.

I think most browsers have facilities (either natively or even through certain browser extensions) do accomodate for this.

Moreover,

A mechanism is available to allow users to print page content with the presentation changes made by the user.

This once again needs to be done by the browser. As a developer, I would have little or no control over this. Even if developers provide a good print stylesheet for their website, the SC states that user can make changes to it and print it. This is not something a developer has control over. This is something that browsers need to allow for.

Would be great to know what would be required from web developers (if anything at all) to meet this criteria.

Unless anyone can expand on how this is an author responsibility, I would say it falls in the user agent domain and should be retired. I couldn't find any background in the LVTF notes to explain the rationale. @slhenry or @emanser can you give some rationale?

Hi Jim,
If this is the problem we are attempting to solve, then a) we should come right out and say so*, and b) I'll echo the concerns voiced by others - what should the content author do to meet this Success Criteria?
(* in plain English - browsers break print output when content is zoomed)

If browser zoom + print "breaks" the printed output, what can I as a web developer (or better-yet/worse) a content author adding content to a CMS via a WYSIWYG editor, do to correct that?

If browser zoom + print "breaks" the printed output, what can I as a web developer (or better-yet/worse) a content author adding content to a CMS via a WYSIWYG editor, do to correct that?

The problematic zoom here is independent from the regular zoom used for viewing/browsing. It's the zoom factor specific to the print preview (IE has similar setting; note Chrome does not have any zoom in its print preview/dialog).

Arguably it's a failing on the part of the browser's layout engine for print (it seems to strip out some CSS/styling, but not other things) by default. I guess the only technique under an author's influence would be to provide explicit @media print... styles that undo problematic things such as absolute positioning, multi-column layouts that overlap, etc. It feels like a variant of text resize, but specifically for the print media type.

Hi @mbgower, I think Allan has some good examples. @allanj-uaag is it ok to publish those links you shared with the LVTF yesterday?

The thing is that for some websites you can increase the size of content (e.g. with zoom) and they display ok, but then they have print stylesheets with fixed heights (I think) that makes the printed version unreadable.

There is some work to do for defining the techniques/failures, but this SC is essentially the requirement.

I'm wondering if we can turn the SC around to saying something like this?

Printing a webpage with the presentation changes made by the user maintains those changes.

Perhaps bring in a concept of 'main' (i.e. the ARIA role) to exclude header, navigation etc?

To me it is an author CSS issue.

To the extent we can isolate author techniques that support or constrict this. More details, please. However, it's not just an author CSS issue, right? As per my first comment

is there any possibility of a failure based on the font substitution between the printer and the screen? Same goes for a screen layout that exceeds the printable size of the paper. At some point the printer is going to have to modify the precise view of the user to fit things to a standard page. Some language around this not being a failure would be helpful.

As well, depending on how a page is printed, this either relies on the user agent or operating system print functions. If those don't support zoom (as seems to be the case with the most popular browser, Chrome) then the language infers that this falls to the author to support. I realize some folks are arguing that "mechanism" in SC doesn't mean an author has to provide the mechanism, but having been part of months' long discussions (and eventual capitulations) with government clients who have insisted on incorrectly interpreting WCAG language, I can tell you that a significant percentage of folks will interpret

A mechanism is available to allow users to print page content with the presentation changes made by the user

to mean that the author is responsible for providing a print function that supports this if there is no other means; these are authoring guidelines, after all. Finally, in an enterprise environment with locked down desktops, switching to another browser may not be a choice.

The "mechanism" confusion can be addressed if the wording was changed to something like:

To the extent allowed by a user agent, users can print page content with their presentation changes preserved.

There are a number of the SCs such as #74 where wording has followed such a tactic.

Also, we have to ask if this is beyond the scope of WCAG content, which applies to content at an HTTP address, and does not apply downloaded or printed material... that's where WCAG2ICT starts to come in... . I think the fact that we as experts in accessibility are struggling to find examples, and ways to do this means this sounds like a WCAG.NEXT or maybe silver issue. I think it's reasonable to retire it for 2.1 or a very limited SC the ensures print style sheets don't over ride the user style or zoom... in which case it sounds like a candidate to roll into #78 which encompasses #74, #78, #79

Did some very basic testing, and just wanted to point out: zoom level when browsing is not carried over in any browser when going to print. Regardless of what zoom factor you had while navigating the site, printing always defaults to regular un-zoomed view (in Chrome, Firefox, Safari, IE, Edge, Opera, Vivaldi, Brave). Some browsers (Firefox and IE) offer print preview with explicit scaling, all others don't seem to offer anything of the sort (unless you go directly into advanced printer settings) it seems.

Perhaps bring in a concept of 'main' (i.e. the ARIA role) to exclude header, navigation etc?

That is at a bit better as that is at least something the author can control, but then in that case I think the wording in this SC needs to drastically change to reflect this.

Updated the issue description to reflect the FPWD text

Added SC for Viewing and SC for Editing links, but this SC does not appear to be in the Full Draft Guideline yet https://rawgit.com/w3c/wcag21/printing_ISSUE-76/guidelines/#printing
@michael-n-cooper is this something you can check?

Hi John,

You wrote:

I've tried to outline my concerns on list.

Thank you very much. Good ideas! Print stylesheets may indeed be a key. Perhaps site owners/content creators could even be required to provide print stylesheets.

If others want to put in that effort then I welcome their attempts,

If I recall correctly @slhenry has done research on printing and was the driver behind this SC. Perhaps she may be interested.

but for my part I am convinced at this time that this is seriously broken and needs extensive re-factoring, and I honestly don't have the time to invest on that task at this point in time.

Understood. Thank you very much for your help and time, John.

Laura

Related to Shawn's statement about PDF, it relates to a point I made on the call. Most web content is displayed independent of the concept of a "page". However, EPUB/PWP/PDF and other formats do have pages and the page concept has utility for people while also raising issues like this one. A classroom using a printout of a paged document has a primary way to draw a connection between the printout and the electronic version and that connection is the page that content appears on.

If a classroom teacher is looking at an electronic version and says "check out this passage on page 45" and the student has a document with large printing and extra space after headings and other adaptations they will know to start looking after page 45 but won't know whether to look on page 60 or 120. I'm sure that there are possible ways to address that such as putting "page 45(1)" and "page 45(2)" etc to maintain a reference to the original page, but this doesn't exist today.

Even if we think that there is a way to do this for HTML-based web content, we need to exempt paged content somehow until there is a way to do this. I'm also wondering how applications meet this. If we expect that this will be part of the EN 301 549 update, we may want to keep the "When a page can be printed" intro (@johnfoliot that was requested because someone indicated that some sites have security settings that prevent printing and without that this SC wouldn't be able to be tested).

@johnfoliot This isn't about supporting two states -- that's another straw man -- your favorite argument technique by the way -- it's about defining a level of tolerance that will allow some adaption but still be obtainable for most sites. Just as we have 200% text resize requirement in WCAG 2 even though many people with low vision need more.

This is sounding like it is not at a consensus. Should a consensus emerge before EOD this Friday with SC text and definitions in GitHub we can still go forward with the CFC, otherwise the chairs are going to declare this not reaching consensus and we will skip the CFC.

• Just as much as we have a SC for Adapting text Adapting text #78 there’s a need for this for print as well.
• Just as much as a content writer has influence on the outcome in the browser (CSS) he has as much influence for the print.
• Just as much as there’s a threshold for what the boundaries are (line height , spacing underneath paragraphs, letter spacing, word spacing) this is needed for print as well.

A scenario could be that you’ll fully comply with 1.4.13 but still fail the desired print outcome.

Why:

• Content writer creates CSS for web page (and also add lots of specific print CSS)
• User overwrites / adapts styling with succes (in browser),but…
• When he prints the outcome fails as he doesn’t know, isn’t aware the print CSS is messing things up.

This can be tested and prevented by the content writer (same as for 1.4.13 but with @media print CSS as well)

Although @johnfoliot is always a good read and pushes the limits to new heights this certainly makes it a content writer issue not a UA issue as John mentioned a couple of times.
The fact that we have multiple options / settings provided by the Browsers / User Agents, also for printing, is not something we can take into consideration when testing proposed SC, do we?

Just like we don’t test a websites with the inverted colours browser option and than failing SC 1.4.3 Contrast because of the colors, we should not go into the road of specific browser print settings.

I also had the feeling after the call Tuesday print might possibly be ‘adapted’ by 1.4.13 instead of it’s own SC. Just as @mbgower mentioned at #76 (comment). But stand alone would also do.

One day for consensus is hard though… :-)

I also had the feeling after the call Tuesday print might possibly be ‘adapted’ by 1.4.13 instead of it’s own SC. Just as @mbgower mentioned at #76 (comment). But stand alone would also do.

Given all considerations, it seems best to leave this separate for now, at Level AAA.

Folks,
We are up against a "line in the sand" with timing to get into the 2.1 draft for further consideration, and there seems to be unresolved misunderstandings. Some feel strongly about including it in this next draft of 2.1, while others raise issues.

Considering the discussion history, we've had instances where old versions of SC were being referenced and commented upon, and instances when specific concerns have been raised but were unclear to some participants. It would be a shame to have the SC blocked from further consideration, while a few remaining points are hashed out.

Please see the updated proposal at the top of #76 – that has the latest wording, definitions, an example test, and Level AAA.

As SC manager, I propose that we advance #76 in order to allow time to clear up misunderstandings, develop shared understanding, and get public feedback.

@emanser as per my last comment, the latest wording has dropped any mention of adapted text. Yet people continue to refer to this. Can you please confirm that you are now proposing this go forward with no mention of adapted text. For instance, I don't see how Jim can assert what is and isn't out of scope given the lack of language in the current wording at https://rawgit.com/w3c/wcag21/printing_ISSUE-76/guidelines/sc/21/printing.html

Okay, but just to explain Jim, when you say to look at the issue, the first thing folks see are links to

SC for viewing | SC for editing
SC in full draft guideline

So even that direction isn't clear. So you are saying that we should consider the following:

When a page can be printed, essential information is printed with no loss of content or adapted text properties.
Note to reviewers: This is not about zoom, or font-size, or paper size, or browsers.

@johnfoliot the hypothetical page we’re printing here, wouldn’t it pass the A3 by default and be broken with the A4 to begin with? Even without the adapted text properties?

This could mean we should first have a SC demanding a page could be printed without loss at all and adding up to not breaking it also with adapted text properties present?! Or if the default is already not printing correct at A4 but is at A3, change the wording to cover this scenario, like:

“When a page can be printed, essential information is printed with no -EXTRA- loss of content or adapted text properties.”

(This because the loss was already there..)

By the way, when reading the Description this SC is not only about adapted text properties but essential information to be printed. So other blocking @media print CSS like display: none on essental elements should also be taken into account.

Print ought to be part of responsive design. the printer is just another device. Authors figured it out for all the devices with different screen sizes.

Jim and John, before we use up a lot of space talking about hypothetical printer scenarios, I think we can probably focus on this statement of Jim's to help get this resolved.

There are now who-knows-how-many screen sizes and mobile form factors, yet we have passed #78 Adapting Text with consensus that a single test can satisfy meeting this on any screen (see "Testability" H2). We can use the identical test to test printing of adapted text.

If it is deemed necessary, it is simple enough in the Understanding doc to add information stating the intent is to test on a standard printer using its standard default setttings. I don't think we need do more than reference ISO information on this. A very quick search showed a printing site that gives more information on scale and magnification factors for printing than I think anyone wants. If some company wants to go to ridiculous lengths to pass all its sites by printing on a large format plotter, I don't think that need be our concern (and I'm also not convinced it would alter the results of the test).

Ultimately this seems to come down to a very few techniques either to do or avoid on the part of the author to achieve -- assuming they've also achieved #78.

I'll note that on that basis, I still think this SC's future is to be subsumed by #78. Looking at the quote of Jim's that started this, I think that is a logical conclusion. If people feel strongly they want to keep it separate for now, I'm not going to lose too much sleep on it (even though I lay tossing and turning about this for some time last night!). But I really do feel that this can be covered by the Testability in #78 with minor changes to the language. (I numbered the first line and added one line, numbered 2, and removed "or functionality".) When two tests are so closely aligned, they suggest to me that there is potential to consolidate:

1. Using a bookmarklet, user stylesheet, or VIP-PDF Reader change:

• line height (line spacing) to at least 1.5 times the font size
• spacing underneath paragraphs to at least 2 times the font size
• letter spacing (tracking) to at least 0.12 times the font size
• word spacing to at least 0.16 times the font size
• font family to a different font family (e.g. Verdana if that is not in use)
• foreground color and background color to a different foreground color and background color (e.g. white on black if that combination is not in use)

2. Print the content (using the user agent's default printer settings)

Expected Results
No loss of content.

Note that my comments on needing some language to cover any printing restrictions intentionally set by the author still apply (i.e., where the author-supplied printer function is intended to precisely mimic the layout of an official document), which I think is a similar problem/concern to AWK's comments about page-defined content

if he and I were to test the same page, we would get different results using ​ our individual​ "default" settings.
​ That's a problem.​

I don't think it is a problem. The language accommodates that. The text would/should simply reflow to the page formatting of the printer. The test is not to see if the results are identical. The test is to see if information is lost/obscured.

Your comment about how to handle links is interesting, but that just sounds like a technique. As for your comment on it affecting the layout, there is no language here stating a layout must be maintained. Reflow -- even stacking information -- is not restricted.

re: overflow:auto... I'm not the most competent CSS user, but I'd assume that a print specification to overflow:visible would address this? Again, sounds like a technique.

images. Good point. Should be possible to use the same language from zoom "except for parts of the content which require two-dimensional layout for usage or meaning."

Please note that I voted -1 on this on Tuesday, for concerns with it being half-baked. This discussion highlights that it still requires thought. However, it seems a lot more contained and closer to success than the COGA ones you mentioned. So it seems worthwhile chipping away at it to try to get consensus. However, I've used up my available cycles, so I'm going to have to sign off.

Did not reach consensus, so deferring