RE: CFC - Printing SC


-1

As much as I would like to see the content writer part take the responsibility to able users to print properly I tend to agree with John and would like to see it much more scoped. It is not ready as much as other SC are. Would like to see more work done before sending if off to the world.


From: John Foliot [mailto:john.foliot@deque.com]
Sent: zaterdag 26 augustus 2017 20:37
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: CFC - Printing SC

​> If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline.


STRONG OBJECTION: I am unable to live with this decision at this time with the currently incomplete draft text.​


I have previously raised serious concerns on this list in regard to this proposed SC, and they have not been adequately answered. Additionally, there were multiple voices on Tuesday's call<https://www.w3.org/2017/08/22-ag-minutes.html#item02> stating that this SC was "half-baked" or incomplete, and nothing has emerged since then to substantially change that perspective.

At the risk of sounding like a broken record, I will restate my concerns here as part of my Objection:

ISSUES:

  *   Testability: I have previously raised concerns regarding the testability of this SC. My own personal testing has shown that page size, page orientation, and even page print-margins have a material and direct impact on whether or not content "passes" or "fails" this SC, yet those testing parameters are currently undefined.

Additionally, I have previously demonstrated how I can modify an "Oversized" page sizing in the PDF print dialog to accomodate pages of *any* size (my example was 20 inches wide), which means that because page size is not defined in the current Draft, I could successfully meet this requirement 100% of the time as long as the page is "big enough".

(I note as well that while the SC alludes to "printing" as being paper-based, the fact that I could "print" a PDF at 20" by 30" for local storage and retreival is not explicitly ruled out, even though that scenario would not meet the stated justification in the SC which states: "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.")

Without accurate and detailed test parameters, this SC cannot be properly tested for compliance.

  *   Text Hyperlinks: The current draft states "When a page can be printed, essential information is printed with no loss of content or adapted text properties." I have previously asked about the impact of printing out pages with text hyperlinks, and the fact that the URLs will be "lost" when pages with text-only hyperlinks are present.

Is that not also "loss of essential information"?

Despite asking for clarification on this point, none has come forward.

  *   Scrolling Content inside of page divs or iFrames: Once again, if a page has a scrollable region embedded somewhere on the page, when printed not all content will be rendered - only the visible content inside the scrollable region. This will make any page with a scrollable region non-conformant.

Is the intent of this SC to forbid scrollable regions on web pages?

Again, while I have raised this concern, I have not received a suitable or reasonable response.

  *   Images that exceed the physical dimensions of a printable page: This issue is doubly frustrated by the fact that print page dimensions and orientation have not been defined. A complex infographic that exceeds 2550 pixels in width will simply not print on standard North American sized pages (unless those pages are in Landscape mode).

Is the intent of this SC to forbid the use of graphics that exceed 2550 pixels? (or 3300 pixels, aka 11 inches)

  *   The Role of User Agents in this SC: Some early testing by myself has also raised the concern over printing defaults set by the browsers and printers. As Jim Allan stated<https://github.com/w3c/wcag21/issues/76#issuecomment-324988860>: "​the browser handles the breakpoints for paper sizes." If this is the case, how can we make this an Authoring issue, short of demanding a complete adaptive print stylesheet for every website? (Note to Jim: 'traditionally' browsers will handle printing breakpoints, unless the author has specifically supplied them using the CSS page-break attribute<https://www.w3.org/wiki/CSS/Properties/page-break-after>. To meet this SC, would not the adaptive stylesheet also need to override the content author's use of this attribute as well, as it may directly impact whether or not content may go "missing"?)

Additionally, are we confident today that all browsers share the same printing defaults? What of evaluators who may have made changes to their print-setup for personal reasons? Without specifying the print parameters (above) we will get plenty of disparate test results.

  *   Conflicts with existing author-supplied stylesheets: The current draft states that for testing purposes, a rudimentary 'adaptive' print style sheet be used that adjusts line-height, letter-spacing, word-spacing, and paragraph padding only.

However variables related to content-containers (width and height), as well as issues around the use of CSS page-break attributes, EPUB pagination of content, the fact that background colors traditionally do not print (and so for example some text content would "disappear" as being white text on white paper) and more, could potentially result in nonconformance. All of these issues are potential 'failures', yet are noticeably absent from a proposed SC simply entitled "Printing".

While I have only mentioned my concern over the CSS page-break attribute once, there have also been previous enquiries from others (AWK) around the issue of pagination that have not been adequately addressed.

It is my belief that these are serious and significant issues that far transcend minor editorial adjustments, and this draft is woefully incomplete. In addition to the specific issues raised above, it does not address in any meaningful way the role that CSS grid systems<https://www.webpagefx.com/blog/web-design/responsive-css-grid/> have on modern websites today, as it appears to presume only basic layouts and text-heavy content.

I appreciate that all of the Task Forces wanted to see all of their SC move forward, but earlier this week we also had to say "no" to a number of incomplete SC from the COGA TF with regard to Tuesday's cut-off date. I fear that this SC, being as incomplete as it is now, will negatively reflect on the impression of quality of *ALL* of our newly proposed SC being advanced "to the next round".

It is simply not ready.

JF




On Sat, Aug 26, 2017 at 8:11 AM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
Call For Consensus — ends Tuesday August 29st at 11:59pm Boston time.

The Working Group has reviewed and approved a new SC on Printing for inclusion in the Editor’s Draft, with the goal of obtaining additional input external to the working group.

Call minutes: https://www.w3.org/2017/08/22-ag-minutes.html#item02


The new Success Criteria can be reviewed here, in the context of the full draft:
https://rawgit.com/w3c/wcag21/printing_ISSUE-76/guidelines/#printing


If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk





--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------

Received on Sunday, 27 August 2017 07:42:56 UTC