This repository has been archived by the owner. It is now read-only.

Printing Customized Text #76

Closed
allanj-uaag opened this Issue Dec 1, 2016 · 70 comments

Comments

Projects
None yet
@allanj-uaag
Contributor

allanj-uaag commented Dec 1, 2016

Current versions of SC and Definitions

SC Shortname

Printing

SC Text

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.

Suggested Priority Level

Level AAA

Related Glossary additions or changes

adapted text properties
changes made to the style properties by the user as per SC1.4.13

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4

Description

It is difficult for some people to read text on the computer; they need to be able to print electronic text on paper in order to read it. For example:

  • 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.
  • 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.

Additionally, sometimes people need to print text to use it away from the computer, for example, recipes, repair instructions, and material for a meeting.

Some people need to change the text display (larger text, more space between lines, etc.) in order to read it, which is covered in other Success Criteria. They also need to be able to print the text so that they can read it. That is, users can change the display of text on the screen, and then print it with the same display aspects.

Testability

Print the page. Check to see that essential content is printed with no truncated text on right edge of content, no overlapping content, etc.

Print with the following

@media print {
    body {
        line-height: 1.5;
        letter-spacing: .12em;
        word-spacing: .16em;
    }
    p {
        padding-bottom: 2em;
    }
}

Check to see that essential content is printed with no truncated text on right edge of content, no overlapping content, etc.

Techniques

Existing Relevant Techniques

  • G179: Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width. Note: LVTF believes this should include container height
  • G146: Use liquid layout
  • C28: Specifying the size of text containers using em units.
  • SCR34: Calculating size and position in a way that scales with text size

New Techniques

  • Print Preview
  • Reader View

Related Information

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 6, 2017

Contributor

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?

Contributor

mbgower commented Jan 6, 2017

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?

@emanser

This comment has been minimized.

Show comment
Hide comment
@emanser

emanser Jan 6, 2017

Happy to pick this one up too as SC Manager

emanser commented Jan 6, 2017

Happy to pick this one up too as SC Manager

@awkawk awkawk changed the title from Printing Customize Text - Ready for Review to Printing Customize Text Jan 9, 2017

@awkawk awkawk changed the title from Printing Customize Text to Printing Customized Text Jan 9, 2017

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 18, 2017

Contributor

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?

Contributor

DavidMacDonald commented Jan 18, 2017

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?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 18, 2017

Member

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?

Member

patrickhlauke commented Jan 18, 2017

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?

@shwetank

This comment has been minimized.

Show comment
Hide comment
@shwetank

shwetank Jan 19, 2017

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.

shwetank commented Jan 19, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 19, 2017

Contributor

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?

Contributor

mbgower commented Jan 19, 2017

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?

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Jan 19, 2017

Contributor
Contributor

allanj-uaag commented Jan 19, 2017

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Jan 19, 2017

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?

johnfoliot commented Jan 19, 2017

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?

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Jan 19, 2017

Contributor
Contributor

allanj-uaag commented Jan 19, 2017

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 19, 2017

Member

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.

Member

patrickhlauke commented Jan 19, 2017

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.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 20, 2017

Contributor

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?

Contributor

alastc commented Jan 20, 2017

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?

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 20, 2017

Contributor

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.

Contributor

mbgower commented Jan 20, 2017

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.

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Jan 20, 2017

johnfoliot commented Jan 20, 2017

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Jan 20, 2017

Contributor
Contributor

allanj-uaag commented Jan 20, 2017

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 25, 2017

Contributor

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

Contributor

DavidMacDonald commented Jan 25, 2017

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

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 25, 2017

Member

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.

Member

patrickhlauke commented Jan 25, 2017

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.

@shwetank

This comment has been minimized.

Show comment
Hide comment
@shwetank

shwetank Jan 27, 2017

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.

shwetank commented Jan 27, 2017

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.

allanj-uaag added a commit to allanj-uaag/wcag21 that referenced this issue Feb 16, 2017

allanj-uaag added a commit to allanj-uaag/wcag21 that referenced this issue Feb 16, 2017

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 27, 2017

Member

Updated the issue description to reflect the FPWD text

Member

awkawk commented Feb 27, 2017

Updated the issue description to reflect the FPWD text

@emanser

This comment has been minimized.

Show comment
Hide comment
@emanser

emanser May 24, 2017

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?

emanser commented May 24, 2017

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?

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 3, 2017

Contributor

SC changed new SC Text
"Essential information can be printed with no loss of content."

thoughts and comments please.

Contributor

allanj-uaag commented Aug 3, 2017

SC changed new SC Text
"Essential information can be printed with no loss of content."

thoughts and comments please.

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma Aug 13, 2017

Contributor

The SC Text lacks the addition of ‘not influencing’ the “Adapting Text #78” properties (when set by the user). This is not only a “browser zoom - Print result / loss of content” SC but also indeed a “@media print…” SC.

As can be read in the Description:

Some people need to change the text display (larger text, more space between lines, etc.) in order to read it, which is covered in other Success Criteria. They also need to be able to print the text so that they can read it. That is, users can change the display of text on the screen, and then print it with the same display aspects.

Focussing on print CSS I do see the need for this SC and a addition to it for user set properties.
This based on lots of experience with extensive print CSS for very richly filled (insurance) internet pages. Specific elaborated print demands for the web pages were done by customising the “@media print” file extensively. Resulting in lots of influence on the content / containers shown, layout and typography on the print.

In this case I clearly see why we need this SC with an addition, like:

Essential information can be printed with no loss of content and or adapted text properties

I also would like to see this back in the Testability part and in techniques where we make sure print CSS doesn't obstruct user settings and or hide essential content.

As @david mentioned #76 (comment) I do not agree this one should be retired but a +1 for the “don’t over ride” part.

I think it's reasonable to retire it for 2.1 or a very limited SC that ensures print style sheets don't over ride the user style or zoom

Contributor

jake-abma commented Aug 13, 2017

The SC Text lacks the addition of ‘not influencing’ the “Adapting Text #78” properties (when set by the user). This is not only a “browser zoom - Print result / loss of content” SC but also indeed a “@media print…” SC.

As can be read in the Description:

Some people need to change the text display (larger text, more space between lines, etc.) in order to read it, which is covered in other Success Criteria. They also need to be able to print the text so that they can read it. That is, users can change the display of text on the screen, and then print it with the same display aspects.

Focussing on print CSS I do see the need for this SC and a addition to it for user set properties.
This based on lots of experience with extensive print CSS for very richly filled (insurance) internet pages. Specific elaborated print demands for the web pages were done by customising the “@media print” file extensively. Resulting in lots of influence on the content / containers shown, layout and typography on the print.

In this case I clearly see why we need this SC with an addition, like:

Essential information can be printed with no loss of content and or adapted text properties

I also would like to see this back in the Testability part and in techniques where we make sure print CSS doesn't obstruct user settings and or hide essential content.

As @david mentioned #76 (comment) I do not agree this one should be retired but a +1 for the “don’t over ride” part.

I think it's reasonable to retire it for 2.1 or a very limited SC that ensures print style sheets don't over ride the user style or zoom

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 16, 2017

Contributor

@jake-abma Thanks for your comments. There are also issues where printing is not allowed because of security or device/software limitations.

Proposed:
Where a page can be printed, essential information can be printed with no loss of content and or adapted text properties.

Contributor

allanj-uaag commented Aug 16, 2017

@jake-abma Thanks for your comments. There are also issues where printing is not allowed because of security or device/software limitations.

Proposed:
Where a page can be printed, essential information can be printed with no loss of content and or adapted text properties.

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma Aug 22, 2017

Contributor

Just to make the power of the content writer over the user clear, the following will result in a printed totally white page or a printed page with blocks of content not visible.

The user can't fix this unless overwriting these classes which can be very specific.

@media print {
  body {
    display: none !important;
  }
}

OR

@media print {
  .class-x {
    display: none !important;
  }
}
Contributor

jake-abma commented Aug 22, 2017

Just to make the power of the content writer over the user clear, the following will result in a printed totally white page or a printed page with blocks of content not visible.

The user can't fix this unless overwriting these classes which can be very specific.

@media print {
  body {
    display: none !important;
  }
}

OR

@media print {
  .class-x {
    display: none !important;
  }
}
@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma Aug 22, 2017

Contributor

This makes a strong case to prevent a content writer do this, specially when this also affects user adjusted styling.

Contributor

jake-abma commented Aug 22, 2017

This makes a strong case to prevent a content writer do this, specially when this also affects user adjusted styling.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Aug 22, 2017

Contributor

Agree that this is not just a user agent issue and something authors have control over. Since this visible printed page appears in user agent before printing this is relevant to web content as it appears in the browser from a single URI -- it is web content.

Contributor

mraccess77 commented Aug 22, 2017

Agree that this is not just a user agent issue and something authors have control over. Since this visible printed page appears in user agent before printing this is relevant to web content as it appears in the browser from a single URI -- it is web content.

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma Aug 22, 2017

Contributor

@mraccess77 true, the user agent follows the CSS rules

Contributor

jake-abma commented Aug 22, 2017

@mraccess77 true, the user agent follows the CSS rules

@slhenry

This comment has been minimized.

Show comment
Hide comment
@slhenry

slhenry Aug 22, 2017

Contributor

Minor tweaks and draft definitions based on 22 August telecon:

When a page can be printed, essential information is printed with no loss of content or adapted text properties. (Level AAA)

definitions:

Contributor

slhenry commented Aug 22, 2017

Minor tweaks and draft definitions based on 22 August telecon:

When a page can be printed, essential information is printed with no loss of content or adapted text properties. (Level AAA)

definitions:

@slhenry

This comment has been minimized.

Show comment
Hide comment
@slhenry

slhenry Aug 22, 2017

Contributor

The main issue is that users with low vision adapt the text so they can read it, and then need to print it. Authors can write CSS that results in overlapping content, or truncated content when printed – for example, because user increased the line spacing.

Thus this issue is indeed within author control and disproportionally effects users with low vision.

Below is a rough example of author's CSS resulting in loss of information/content with adapted text. (There are better examples, I just kludged this together to show author messing up printing for users with low vision.)

Default page on screen – looks fine:
eg-screen

Default page printed – looks fine:
eg-screen-print-preview

User CSS applied to page on screen – looks fine:
eg-screen-usercss
(they scroll to get the rest of it)
eg-screen-usercss2

User CSS applied to page printed – loss of content:
eg-screen-usercss-print-preview

The ingredients list and the directions are both cut off. (not just available on a second page)

This is because of the author's CSS:

<style media="screen">
.section1 {
	float: right;
	padding: 7px;
	border: 1px solid green;
}
.section2 {
	padding: 16px;
	border: 1px solid magenta;
}
</style>
<style media="print">
.section1 {
	max-width: 150px;
	max-height: 300px;
	padding: 7px;
	border: 1px solid green;
	float: right;
	overflow: hidden;
}
.section2 {
	max-width: 600px;
	max-height: 800px;
	padding: 16px;
	border: 1px solid magenta;
	overflow: hidden;
}
Contributor

slhenry commented Aug 22, 2017

The main issue is that users with low vision adapt the text so they can read it, and then need to print it. Authors can write CSS that results in overlapping content, or truncated content when printed – for example, because user increased the line spacing.

Thus this issue is indeed within author control and disproportionally effects users with low vision.

Below is a rough example of author's CSS resulting in loss of information/content with adapted text. (There are better examples, I just kludged this together to show author messing up printing for users with low vision.)

Default page on screen – looks fine:
eg-screen

Default page printed – looks fine:
eg-screen-print-preview

User CSS applied to page on screen – looks fine:
eg-screen-usercss
(they scroll to get the rest of it)
eg-screen-usercss2

User CSS applied to page printed – loss of content:
eg-screen-usercss-print-preview

The ingredients list and the directions are both cut off. (not just available on a second page)

This is because of the author's CSS:

<style media="screen">
.section1 {
	float: right;
	padding: 7px;
	border: 1px solid green;
}
.section2 {
	padding: 16px;
	border: 1px solid magenta;
}
</style>
<style media="print">
.section1 {
	max-width: 150px;
	max-height: 300px;
	padding: 7px;
	border: 1px solid green;
	float: right;
	overflow: hidden;
}
.section2 {
	max-width: 600px;
	max-height: 800px;
	padding: 16px;
	border: 1px solid magenta;
	overflow: hidden;
}
@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Aug 22, 2017

Contributor

Playing devils advocate a bit here, but can't this be solved at the user-agent end? If you are adapting text already, why not adapt the layout for print as well?

I.e. use a similar method to the linearisation bookmarklet, so something like:

* {
   float: none; 
   max-width: 100%;
   position: static;
   display: block;
   width: auto;
   height: auto;
   text-align: left;
}
img { 
   max-width: 90%;
   max-height: 90%;
   display: block;
}

(Add !important to each value to make sure you override things, I left that out for clarity). The JavaScript version is slightly cleverer, but that's the basic idea: flatten everything.

Where this becomes an author issue would be things like dynamic layouts that change or at least apply styles from JS. However, if you can override text and get odd behavior, maybe it is a matter of overriding more aspects?

Contributor

alastc commented Aug 22, 2017

Playing devils advocate a bit here, but can't this be solved at the user-agent end? If you are adapting text already, why not adapt the layout for print as well?

I.e. use a similar method to the linearisation bookmarklet, so something like:

* {
   float: none; 
   max-width: 100%;
   position: static;
   display: block;
   width: auto;
   height: auto;
   text-align: left;
}
img { 
   max-width: 90%;
   max-height: 90%;
   display: block;
}

(Add !important to each value to make sure you override things, I left that out for clarity). The JavaScript version is slightly cleverer, but that's the basic idea: flatten everything.

Where this becomes an author issue would be things like dynamic layouts that change or at least apply styles from JS. However, if you can override text and get odd behavior, maybe it is a matter of overriding more aspects?

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Aug 23, 2017

Contributor

@johnfoliot wrote ". So any changes made by the end user will potentially make the content non-printable (as desired), but not because of anything the content author has done.

That's no the point. We aren't saying that the page fails if the user chooses to use white on white. The case we are talking about is when the authors styles do not support the users adaptions for adapting spacing, font and other similar things called out by our adapting text SC.

@johnfoliot wrote [If a "few pages print overlapping or truncated content" is it perhaps
because the end-user hasn't modified their user style sheet sufficiently?]

It could be or it could be that the page was created in a way that makes it not possible.

@johnfoliot "How would I as an evaluator/conformance tester be able to ascertain whether
changes to a user style-sheet you've made post-publication will affect
the printing - how is this testable?

Again -- by applying a style sheet like that one we created for adapting text that will change certain things such as line spacing.

Contributor

mraccess77 commented Aug 23, 2017

@johnfoliot wrote ". So any changes made by the end user will potentially make the content non-printable (as desired), but not because of anything the content author has done.

That's no the point. We aren't saying that the page fails if the user chooses to use white on white. The case we are talking about is when the authors styles do not support the users adaptions for adapting spacing, font and other similar things called out by our adapting text SC.

@johnfoliot wrote [If a "few pages print overlapping or truncated content" is it perhaps
because the end-user hasn't modified their user style sheet sufficiently?]

It could be or it could be that the page was created in a way that makes it not possible.

@johnfoliot "How would I as an evaluator/conformance tester be able to ascertain whether
changes to a user style-sheet you've made post-publication will affect
the printing - how is this testable?

Again -- by applying a style sheet like that one we created for adapting text that will change certain things such as line spacing.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 23, 2017

Contributor

Realizing this is very 11th hour, but way back in January the idea of this being merged with #78 Adapting Text came up.
In the last couple of days, there have been several mentions of getting wording similar to Adapting text for the printing functionality.

My question: is not this already acheived through the final wording of #78?

If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

That's my emphasis on the word functionality. Isn't printing a function? Since we're already talking about a page not altering by having a user change various text spacing values, isn't this already covered? Or couldn't it easily be covered as a technique (or failure) specific to printing in #78 using media print queries?

Contributor

mbgower commented Aug 23, 2017

Realizing this is very 11th hour, but way back in January the idea of this being merged with #78 Adapting Text came up.
In the last couple of days, there have been several mentions of getting wording similar to Adapting text for the printing functionality.

My question: is not this already acheived through the final wording of #78?

If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

That's my emphasis on the word functionality. Isn't printing a function? Since we're already talking about a page not altering by having a user change various text spacing values, isn't this already covered? Or couldn't it easily be covered as a technique (or failure) specific to printing in #78 using media print queries?

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Aug 23, 2017

Contributor

Hi @mbgower , @johnfoliot , and all,

Mike wrote:

My question: is not this already achieved through the final wording of #78?

If we go with that line of thinking, I think it would be a big reach and could impact more in WCAG than just the Adapting Text SC. All of the following use the "without loss of content or functionality" wording:

Is it applicable to them all? Perhaps consider (advisory?) printing techniques for them all?

The big question to get agreement on is:
Do people agree that printing is covered under WCAG?

@johnfoliot do you agree that it is?

Laura

Contributor

lauracarlson commented Aug 23, 2017

Hi @mbgower , @johnfoliot , and all,

Mike wrote:

My question: is not this already achieved through the final wording of #78?

If we go with that line of thinking, I think it would be a big reach and could impact more in WCAG than just the Adapting Text SC. All of the following use the "without loss of content or functionality" wording:

Is it applicable to them all? Perhaps consider (advisory?) printing techniques for them all?

The big question to get agreement on is:
Do people agree that printing is covered under WCAG?

@johnfoliot do you agree that it is?

Laura

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 23, 2017

Contributor

@lauracarlson, I think the idea of advisory techniques is a way of incorporating.

I was aware I was stretching the intended meaning of "functionality". Like John, I have always understood the phrase to refer to functionality of the elements and widgets on the web page -- and as he point out, printing the page is under most circumstances done by user agent and OS with no author involvement.
We're focusing on the scenario where the user overrides the author css settings. I guess a grey area for me is when a web application offers its own function (i.e., mechanism) to print the page. At that point, it does feel like the author is assuming some level of burden to format in a way that ensures the successful printing.
But in this scenario, the printing is often an 'official' format (I'm thinking of things like forms from an Insurance Company) which the author may be formatting specifically to meet the physical print media. Would that be excepted here? If not, that seems like an issue.


Actually, as I look at the wording of the SC, I'm hard-pressed to understand how someone would fail it, or how adapting text is even captured as a consideration in the latest version.

Essential information can be printed with no loss of content.

At least in the version I'm looking at "or adapted text properties" has been removed. That seems to make the SC almost valueless.

Contributor

mbgower commented Aug 23, 2017

@lauracarlson, I think the idea of advisory techniques is a way of incorporating.

I was aware I was stretching the intended meaning of "functionality". Like John, I have always understood the phrase to refer to functionality of the elements and widgets on the web page -- and as he point out, printing the page is under most circumstances done by user agent and OS with no author involvement.
We're focusing on the scenario where the user overrides the author css settings. I guess a grey area for me is when a web application offers its own function (i.e., mechanism) to print the page. At that point, it does feel like the author is assuming some level of burden to format in a way that ensures the successful printing.
But in this scenario, the printing is often an 'official' format (I'm thinking of things like forms from an Insurance Company) which the author may be formatting specifically to meet the physical print media. Would that be excepted here? If not, that seems like an issue.


Actually, as I look at the wording of the SC, I'm hard-pressed to understand how someone would fail it, or how adapting text is even captured as a consideration in the latest version.

Essential information can be printed with no loss of content.

At least in the version I'm looking at "or adapted text properties" has been removed. That seems to make the SC almost valueless.

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Aug 23, 2017

Contributor

Hi John,

Thank you for your reply. I agree that it is an accessibility issue and we are running out of time in 2.1.

You wrote:

Do I think it can fully addressed in WCAG? No.

What aspects would you consider in scope for WCAG? @alastc had mentioned dynamic layouts.

If we can identify a few aspects maybe we can think of ways that they could be addressed. Even if we don't have time to do the work now, it would be good to start a list.

Thanks,
Laura

Contributor

lauracarlson commented Aug 23, 2017

Hi John,

Thank you for your reply. I agree that it is an accessibility issue and we are running out of time in 2.1.

You wrote:

Do I think it can fully addressed in WCAG? No.

What aspects would you consider in scope for WCAG? @alastc had mentioned dynamic layouts.

If we can identify a few aspects maybe we can think of ways that they could be addressed. Even if we don't have time to do the work now, it would be good to start a list.

Thanks,
Laura

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 23, 2017

Contributor
Contributor

allanj-uaag commented Aug 23, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Aug 23, 2017

Contributor

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

Contributor

lauracarlson commented Aug 23, 2017

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

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 23, 2017

Member

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).

Member

awkawk commented Aug 23, 2017

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).

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Aug 23, 2017

Contributor

@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.

Contributor

mraccess77 commented Aug 23, 2017

@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.

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 23, 2017

johnfoliot commented Aug 23, 2017

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 24, 2017

Member

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.

Member

awkawk commented Aug 24, 2017

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.

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma Aug 24, 2017

Contributor
  • Just as much as we have a SC for 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… :-)

Contributor

jake-abma commented Aug 24, 2017

  • Just as much as we have a SC for 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… :-)

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 24, 2017

Contributor
Contributor

allanj-uaag commented Aug 24, 2017

@slhenry

This comment has been minimized.

Show comment
Hide comment
@slhenry

slhenry Aug 24, 2017

Contributor

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.

Contributor

slhenry commented Aug 24, 2017

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.

@emanser

This comment has been minimized.

Show comment
Hide comment
@emanser

emanser Aug 24, 2017

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 commented Aug 24, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 24, 2017

Contributor

@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

Contributor

mbgower commented Aug 24, 2017

@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

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 24, 2017

Contributor
Contributor

allanj-uaag commented Aug 24, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 24, 2017

Contributor

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.

Contributor

mbgower commented Aug 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 24, 2017

johnfoliot commented Aug 24, 2017

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 24, 2017

Contributor
Contributor

allanj-uaag commented Aug 24, 2017

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 24, 2017

Contributor
Contributor

allanj-uaag commented Aug 24, 2017

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 24, 2017

Contributor
Contributor

allanj-uaag commented Aug 24, 2017

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma Aug 24, 2017

Contributor

@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.

Contributor

jake-abma commented Aug 24, 2017

@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.

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 24, 2017

Contributor
Contributor

allanj-uaag commented Aug 24, 2017

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 24, 2017

johnfoliot commented Aug 24, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 25, 2017

Contributor

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)
  1. 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

Contributor

mbgower commented Aug 25, 2017

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)
  1. 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

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 25, 2017

johnfoliot commented Aug 25, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 25, 2017

Contributor

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.

Contributor

mbgower commented Aug 25, 2017

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.

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 25, 2017

Contributor
Contributor

allanj-uaag commented Aug 25, 2017

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Aug 25, 2017

johnfoliot commented Aug 25, 2017

@awkawk awkawk added Defer and removed Ready for WG Review labels Sep 12, 2017

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Sep 12, 2017

Member

Did not reach consensus, so deferring

Member

awkawk commented Sep 12, 2017

Did not reach consensus, so deferring

@awkawk awkawk closed this Sep 12, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.