allanj-uaag commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Happy to pick this one up too as SC Manager

DavidMacDonald commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

See the examples - https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Printing_Customized_Text#Examples User is able to change zoom level before printing, and apply styles. However, the pages when viewed in the browser zoom to 200% just fine. but when the user prints at 200% zoom...things fail at times.

On Thu, Jan 19, 2017 at 8:14 AM, Mike Gower notifications@github.com wrote:

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 https://github.com/slhenry or @emanser https://github.com/emanser can you give some rationale?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/76#issuecomment-273786338, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WL0LqYwV20xwsTAflHLCkLAhqj5JWks5rT2-1gaJpZM4LB1rr .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

johnfoliot commented 7 years ago

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 commented 7 years ago

in plain English - browsers break print output when content is zoomed

since some pages work fine and other break. Some pages the browser zoom reflows just fine...the print zoom breaks. To me it is an author CSS issue. will be examining all of the pages to compare and find what in the CSS is causing the issue.

On Thu, Jan 19, 2017 at 4:34 PM, John Foliot notifications@github.com wrote:

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?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/76#issuecomment-273920398, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WL2M1Jmt40IXvE6JIBdfM59sRl7oDks5rT-TvgaJpZM4LB1rr .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

patrickhlauke commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

+10!

JF

On Fri, Jan 20, 2017 at 9:10 AM, Mike Gower notifications@github.com wrote:

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 https://github.com/w3c/wcag21/issues/74 where wording has followed such a tactic.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/76#issuecomment-274094887, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c3i-eE9yjZ0Sitg1huqSbRRhdMN7ks5rUM5ygaJpZM4LB1rr .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

allanj-uaag commented 7 years ago

On Fri, Jan 20, 2017 at 3:32 AM, Alastair Campbell <notifications@github.com

wrote:

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

there are updated examples on the wiki page https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Printing_Customized_Text#Examples

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?

I think this is a good start. Removes "mechanism". Based on discussion in the Low Vision meeting yesterday limiting the scale for printing to 200% seems reasonable. All of the example pages on the wiki page above are at 200%

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/76#issuecomment-274023010, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WLxlfpRhhBAb3p9VGaKlj59OHGlD6ks5rUH8ggaJpZM4LB1rr .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

DavidMacDonald commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

awkawk commented 7 years ago

Updated the issue description to reflect the FPWD text

emanser commented 7 years ago

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 commented 7 years ago

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

thoughts and comments please.

jake-abma commented 7 years ago

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 https://github.com/w3c/wcag21/issues/76#issuecomment-275168816 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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

mraccess77 commented 7 years ago

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 commented 7 years ago

@mraccess77 true, the user agent follows the CSS rules

shawna-slh commented 7 years ago

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:

essential: https://w3c.github.io/wcag21/guidelines/#dfn-essential
adapted text properties: changes made to the style properties by the user as per SC1.4.13
style properties: https://w3c.github.io/wcag21/guidelines/#dfn-style-properties

shawna-slh commented 7 years ago

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:

Default page printed – looks fine:

User CSS applied to page on screen – looks fine:

(they scroll to get the rest of it)

User CSS applied to page printed – loss of content:

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 commented 7 years ago

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 commented 7 years ago

Authors can write CSS that results in overlapping content, or truncated content when printed – for example, because user increased the line spacing.

In that example, the end user has over-written the authors CSS (your Caption for the 4th image: User CSS applied to page printed – loss of content:), so yes, of course it won't work as expected - you overrode some but not all of the important layout information. Even if I were to write a print stylesheet that "worked" in a magnified way, if an end-user then comes along and makes additional changes, what can the original content author do to avoid that?

However, I also need to ask, is this really what end-users will do - write their own custom style sheets for randomly printing individual pages?

I suspect instead that many will instead look to their browser to do this, and helpfully(???) browsers are ready to oblige:

[image: Inline image 1] (Figure 1: screen capture of default print dialog in Chrome)

When I leave the scale at 100(%), as you can see in Figure 1, the page content is formatted to fit on a full 8.5 X 11 page. However, if I adjust that scale value to 200(%), illustrated below in Figure 2, content is now "broken" (truncated, cut-off, etc.):

[image: Inline image 2] (Figure 2: screen capture of print dialog in Chrome, with magnification scale set to 200(%))

In this use-case, the 'problem' is centered directly within the user-agent, and outside of the control of the content author. We have a similar problem in the other browsers as well, including Firefox:

[image: Inline image 3] (Figure 3: screen capture of print dialog in Firefox, with magnification scale set to 200(%))

...and Edge:

[image: Inline image 4] (Figure 4: screen capture of print dialog in Edge, with magnification scale set to 200(%))

The problem as I see it is here:

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

If the end user is making changes to the content's style (whether screen or print), then they have taken over control of the final rendering (whether screen or print), and so it is the end-user who is responsible for ensuring that the adapted text (modified by them via their user style sheet) will print properly.

If the end user is making changes to the rendered content via the tools inside of the browser, then it is the browser that is breaking things (as illustrated above) and not the content author.

In either case, the final rendering is outside the control of the Web Content author.

While I agree that this is an issue, I do not believe it is an issue that can be directly addressed by the content author, as too many other actors and factors can be involved that would frustrate success. I believe this should be handed to the Silver TF as a work item, but I do not think we can turn this into a workable SC in WCAG 2.1 (sorry).

JF

On Tue, Aug 22, 2017 at 4:45 PM, shawn_slh notifications@github.com wrote:

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: [image: eg-screen] https://user-images.githubusercontent.com/6991814/29588844-a007c9d4-8758-11e7-81aa-0e1aa1bd7157.png

Default page printed – looks fine: [image: eg-screen-print-preview] https://user-images.githubusercontent.com/6991814/29588860-ad15842c-8758-11e7-94dd-e23bbe8ef2ab.png

User CSS applied to page on screen – looks fine: [image: eg-screen-usercss] https://user-images.githubusercontent.com/6991814/29588874-b474abee-8758-11e7-877c-087fd5530d55.png (they scroll to get the rest of it) [image: eg-screen-usercss2] https://user-images.githubusercontent.com/6991814/29588891-c3b590c8-8758-11e7-9c52-9cef535f8a5b.png

User CSS applied to page printed – loss of content: [image: eg-screen-usercss-print-preview] https://user-images.githubusercontent.com/6991814/29588900-c8b68ec4-8758-11e7-82da-1feaf23d1eb8.png

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:

w3c / wcag21

Printing Customized Text #76

Current versions of SC and Definitions

SC Shortname

SC Text

Suggested Priority Level

Related Glossary additions or changes

What Principle and Guideline the SC falls within.

Description

Testability

Techniques

Existing Relevant Techniques

New Techniques

Related Information