-
Notifications
You must be signed in to change notification settings - Fork 55
Printing Customized Text #76
Comments
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. |
Happy to pick this one up too as SC Manager |
I don't know technically how a developer would do this? I don't see any techniques on this... I guess we are requiring the site to support client side custom CSS style sheet substitution, and then the new Style sheet added to the browser on the client side would direct the printer on the changes it forced into the client's browser? Is that what we are requiring? |
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? |
For both this and the one below
I think most browsers have facilities (either natively or even through certain browser extensions) do accomodate for this. Moreover,
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. |
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 ***@***.***> 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
<#76 (comment)>, 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
|
Hi Jim, 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? |
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 ***@***.***> 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
<#76 (comment)>, 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
|
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 |
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?
Perhaps bring in a concept of 'main' (i.e. the ARIA role) to exclude header, navigation etc? |
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
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
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:
There are a number of the SCs such as #74 where wording has followed such a tactic. |
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 ***@***.***> 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 <#74> where
wording has followed such a tactic.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#76 (comment)>, 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
|
On Fri, Jan 20, 2017 at 3:32 AM, Alastair Campbell ***@***.*** > 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
<#76 (comment)>, 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
|
Also, we have to ask if this is beyond the scope of WCAG content, which applies to content at an HTTP address, and does not apply downloaded or printed material... that's where WCAG2ICT starts to come in... . I think the fact that we as experts in accessibility are struggling to find examples, and ways to do this means this sounds like a WCAG.NEXT or maybe silver issue. I think it's reasonable to retire it for 2.1 or a very limited SC the ensures print style sheets don't over ride the user style or zoom... in which case it sounds like a candidate to roll into #78 which encompasses #74, #78, #79 |
Did some very basic testing, and just wanted to point out: zoom level when browsing is not carried over in any browser when going to print. Regardless of what zoom factor you had while navigating the site, printing always defaults to regular un-zoomed view (in Chrome, Firefox, Safari, IE, Edge, Opera, Vivaldi, Brave). Some browsers (Firefox and IE) offer print preview with explicit scaling, all others don't seem to offer anything of the sort (unless you go directly into advanced printer settings) it seems. |
That is at a bit better as that is at least something the author can control, but then in that case I think the wording in this SC needs to drastically change to reflect this. |
Updated the issue description to reflect the FPWD text |
Added SC for Viewing and SC for Editing links, but this SC does not appear to be in the Full Draft Guideline yet https://rawgit.com/w3c/wcag21/printing_ISSUE-76/guidelines/#printing |
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.
Hi Laura,
I've tried to outline my concerns on list.
If others want to put in that effort then I welcome their attempts, 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.
JF
…On Wed, Aug 23, 2017 at 2:16 PM, Laura Carlson ***@***.***> wrote:
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 <#76 (comment)>
:
Do I think it can fully addressed in WCAG? No.
What aspects would you consider in scope for WCAG? @alastc
<https://github.com/alastc> had mentioned dynamic layouts
<#76 (comment)>.
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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c1Ow4Nf5B7vo07n9EgMkNLppMLaOks5sbHqKgaJpZM4LB1rr>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
John,
On Wed, Aug 23, 2017 at 11:56 AM, John Foliot ***@***.***> wrote:
Hi Jon,
> 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.
Adapting content for the screen versus adapting content for print are two
separate functions, both of which are also limited by realities beyond the
control of the page author. For example, most North American printers will
be loaded with paper at 8.5 X 11. If your text adaption is such that it
does not account for this factor, then that is *your* fault, not the page
content author's fault, as you have made changes to the final rendering,
after the author has posted their page/content.
This is a red herring. have tested many sites with plain printing - no css
changes. the browser/os handles the changes for paper size. Author doesn't
need to sweat that detail. If the page works one place it works in all.
|
Hi John, You wrote:
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 I recall correctly @slhenry has done research on printing and was the driver behind this SC. Perhaps she may be interested.
Understood. Thank you very much for your help and time, John. Laura |
Related to Shawn's statement about PDF, it relates to a point I made on the call. Most web content is displayed independent of the concept of a "page". However, EPUB/PWP/PDF and other formats do have pages and the page concept has utility for people while also raising issues like this one. A classroom using a printout of a paged document has a primary way to draw a connection between the printout and the electronic version and that connection is the page that content appears on. If a classroom teacher is looking at an electronic version and says "check out this passage on page 45" and the student has a document with large printing and extra space after headings and other adaptations they will know to start looking after page 45 but won't know whether to look on page 60 or 120. I'm sure that there are possible ways to address that such as putting "page 45(1)" and "page 45(2)" etc to maintain a reference to the original page, but this doesn't exist today. Even if we think that there is a way to do this for HTML-based web content, we need to exempt paged content somehow until there is a way to do this. I'm also wondering how applications meet this. If we expect that this will be part of the EN 301 549 update, we may want to keep the "When a page can be printed" intro (@johnfoliot that was requested because someone indicated that some sites have security settings that prevent printing and without that this SC wouldn't be able to be tested). |
@johnfoliot This isn't about supporting two states -- that's another straw man -- your favorite argument technique by the way -- it's about defining a level of tolerance that will allow some adaption but still be obtainable for most sites. Just as we have 200% text resize requirement in WCAG 2 even though many people with low vision need more. |
Hi Jon,
You can call it what you want (strawman or not), but that isn't solving any
issues. Additionally, for testing purposes if the test isn't "check it in
it's native state, then apply this special style sheet "...that WCAG has
created" (your words) for testing", then how do you propose this to be
tested? Specifically.
I will assert that that is *EXACTLY* what the majority of evaluators will
do: test those 2 states (they aren't going to test the increase font-size
and line height requirement incrementally are they? Even basic QA testing
on responsive sites don't test at every screen size configuration, but
rather at 2 or 3 specific break points)
But as I have repeatedly pointed out, to make it print at a larger font and
line-height scale, *the layout aspects of the CSS* will often-times *also*
need to be modified, and a "basic minimal" sheet (as Shawn noted) simply
cannot do that (unless you can show me otherwise).
I've not seen any examples of how an author could meet this requirement (at
scale) via a custom CSS file, because as Shawn noted earlier "It's a lot of
stinkin' work...", and again, even if the content author provided *one* "*Large
Print*" print stylesheet (as an alternative print sheet) there is no
guarantee it will meet the needs of all users anyway, so...
Finally, the current draft also sidesteps the fact that browsers have
default print style sheets in them as well - and that they can be
'adjusted' in the print dialog. (And if you really want to pick at nits,
what about content that doesn't print well in Portrait mode, but does in
Landscape mode? Pass or Fail? What if, as a disclaimer, the site notes "To
print these pages, you MUST use ledger sized (11" X17") paper for suitable
print outcomes"? I for one have been doing this long enough to anticipate
this kind of response/query in the future, as I'm sure you have as well.)
So, while I agree this is an issue, until you can show me specifically how
to meet this requirement without a wholesale refactoring of a print
stylesheet to address factors beyond font-size, font-face and line height,
I will continue to assert that this is much a User Agent issue as it is a
Content Author issue.
For your average "this is the first and likely last time I'm seeing this
page" NOBODY is going to do the required work to create a modified user
print stylesheet that address both typographical 'adaptations' *along-side
of the additional layout changes* that are sometimes necessitated by the
fact that you are increasing the size of the content.
Instead, as I have suggested, they are going to look for the path of least
resistance - and choose to zoom the content in their browser print dialog
(a feature available in every browser today). I thus conclude that the
appropriate place to address this, in a holistic fashion, is via Project
Silver, as currently User Agents are out of scope for WCAG.
JF
…On Wed, Aug 23, 2017 at 3:50 PM, Jonathan Avila ***@***.***> wrote:
@johnfoliot <https://github.com/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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c46ugkdzwLcSUbogBVnnL1jaEw_aks5sbJCxgaJpZM4LB1rr>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
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. |
A scenario could be that you’ll fully comply with 1.4.13 but still fail the desired print outcome. Why:
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. 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… :-) |
On Wed, Aug 23, 2017 at 5:00 PM, John Foliot <notifications@github.com>
wrote:
Hi Jon,
You can call it what you want (strawman or not), but that isn't solving any
issues. Additionally, for testing purposes if the test isn't "check it in
it's native state, then apply this special style sheet "...that WCAG has
created" (your words) for testing", then how do you propose this to be
tested? Specifically.
I will assert that that is *EXACTLY* what the majority of evaluators will
do: test those 2 states (they aren't going to test the increase font-size
and line height requirement incrementally are they? Even basic QA testing
on responsive sites don't test at every screen size configuration, but
rather at 2 or 3 specific break points)
T
here is nothing about font-size in the SC. The break point is the max
limits set in Adapting Text
@media print {
body {
|
line-height: 1.5;
letter-spacing: .12em;
word-spacing: .16em;}
p
{padding-bottom: 2em;}
}
But as I have repeatedly pointed out, to make it print at a larger font and
line-height scale, *the layout aspects of the CSS* will often-times *also*
need to be modified, and a "basic minimal" sheet (as Shawn noted) simply
cannot do that (unless you can show me otherwise).
There is NO font size.
I've not seen any examples of how an author could meet this requirement (at
scale) via a custom CSS file, because as Shawn noted earlier "It's a lot of
stinkin' work...", and again, even if the content author provided *one*
"*Large
Print*" print stylesheet (as an alternative print sheet) there is no
guarantee it will meet the needs of all users anyway, so...
the only requirement is that it meet the max line-height, letter and word
spacing, and double spacing between paragraphs.
If it can meet the max I would be very surprised if it could not meets any
increment smaller than the requirement.
Finally, the current draft also sidesteps the fact that browsers have
default print style sheets in them as well - and that they can be
'adjusted' in the print dialog. (And if you really want to pick at nits,
what about content that doesn't print well in Portrait mode, but does in
Landscape mode? Pass or Fail? What if, as a disclaimer, the site notes "To
print these pages, you MUST use ledger sized (11" X17") paper for suitable
print outcomes"? I for one have been doing this long enough to anticipate
this kind of response/query in the future, as I'm sure you have as well.)
Default print style sheet is ONLY if there are not other styles. Plain
html with no CSS. any style the author applies will print, unless the
@media or other css overrides.
As to the content that doesn't print well in Portrait...seems the author
should know that already. why should the user have to discover and adjust.
There is CSS to accommodate
layout.
So, while I agree this is an issue, until you can show me specifically how
to meet this requirement without a wholesale refactoring of a print
stylesheet to address factors beyond font-size, font-face and line height,
I will continue to assert that this is much a User Agent issue as it is a
Content Author issue.
The user agent can't fix what the author has done poorly. The user agent
prints according to the styles provided. If the text width is set wider
that the page width, text is truncated. The author can fix that. The user
shouldn't have to. 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.
For your average "this is the first and likely last time I'm seeing this
page" NOBODY is going to do the required work to create a modified user
print stylesheet that address both typographical 'adaptations' *along-side
of the additional layout changes* that are sometimes necessitated by the
fact that you are increasing the size of the content.
agree, However... assuming the author has responsively designed the site
to meet max values in Adapting Text, then it should print fine
... unless the author did something to break it.
Instead, as I have suggested, they are going to look for the path of least
resistance - and choose to zoom the content in their browser print dialog
(a feature available in every browser today). I thus conclude that the
appropriate place to address this, in a holistic fashion, is via Project
Silver, as currently User Agents are out of scope for WCAG.
This is NOT about zoom. It was removed. This is about authors affording
users the ability to print the authors content with adjustments to line
height, paragraph spacing, letter and word spacing without loss of
essential content. All of these are within the authors control.
Jim
…
On Wed, Aug 23, 2017 at 3:50 PM, Jonathan Avila ***@***.***>
wrote:
> @johnfoliot <https://github.com/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.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABK-c46ug
kdzwLcSUbogBVnnL1jaEw_aks5sbJCxgaJpZM4LB1rr>
> .
>
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
***@***.***
Advancing the mission of digital accessibility and inclusion
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WL35i-R8TwJLp_C-xaAfBl_WtHY7pks5sbKEAgaJpZM4LB1rr>
.
--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9452
<(512)%20206-9452> http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
Folks, Considering the discussion history, we've had instances where old versions of SC were being referenced and commented upon, and instances when specific concerns have been raised but were unclear to some participants. It would be a shame to have the SC blocked from further consideration, while a few remaining points are hashed out. Please see the updated proposal at the top of #76 – that has the latest wording, definitions, an example test, and Level AAA. As SC manager, I propose that we advance #76 in order to allow time to clear up misunderstandings, develop shared understanding, and get public feedback. |
@emanser as per my last comment, the latest wording has dropped any mention of adapted text. Yet people continue to refer to this. Can you please confirm that you are now proposing this go forward with no mention of adapted text. For instance, I don't see how Jim can assert what is and isn't out of scope given the lack of language in the current wording at https://rawgit.com/w3c/wcag21/printing_ISSUE-76/guidelines/sc/21/printing.html |
@GowerM
apologies. Please use the text in the Issue
#76
it was forked - https://github.com/allanj-uaag/wcag21/commit/
c2cc244 and hasn't be merged in the
official version
…On Thu, Aug 24, 2017 at 2:41 PM, Mike Gower ***@***.***> wrote:
@emanser <https://github.com/emanser> as per my last comment,
<#76 (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 an 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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WLwPNDbfQDUcmBdkvZnFV-07T1IUGks5sbdHXgaJpZM4LB1rr>
.
--
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
Okay, but just to explain Jim, when you say to look at the issue, the first thing folks see are links to
So even that direction isn't clear. So you are saying that we should consider the following:
|
I have one question (actually, I have a lot, but will limit it to one
here). The current text that Jim just pointed us to states:
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.*
My Question: If I apply the text adaptations noted in the Testability
Section:
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.
...and then send that content to a printer loaded with Ledger-sized paper
(11 X 17 - aka A3) in Landscape Mode, and it all prints "...with no loss of
content or adapted text properties...", then I've successfully met this SC,
correct?
It won't "Pass" with 8.5 X 11 (aka A4) in Portrait mode, but currently this
SC explicitly says that paper size is not a variable in determining Success
or Failure, and so the Ledger@Landscape setting would be "successful".
I just want to be sure I fully understand what is being advanced forward.
JF
…On Thu, Aug 24, 2017 at 3:23 PM, Jim Allan ***@***.***> wrote:
@GowerM
apologies. Please use the text in the Issue
#76
it was forked - https://github.com/allanj-uaag/wcag21/commit/
c2cc244 and hasn't be merged in the
official version
On Thu, Aug 24, 2017 at 2:41 PM, Mike Gower ***@***.***>
wrote:
> @emanser <https://github.com/emanser> as per my last comment,
> <#76 (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 an 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
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-
auth/AG_WLwPNDbfQDUcmBdkvZnFV-07T1IUGks5sbdHXgaJpZM4LB1rr>
> .
>
--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9452 <(512)%20206-9452>
http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-cw9gPJY2IZvCuVWs_b81jn_612IAks5sbdurgaJpZM4LB1rr>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
working on updating the forks. somehow I dont have direct edit
…On Thu, Aug 24, 2017 at 3:38 PM, Mike Gower ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WLxRf2Z6o2gd91cuyOZZubMtpaWG-ks5sbd88gaJpZM4LB1rr>
.
--
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
Issue updated all changes merged
…On Thu, Aug 24, 2017 at 4:02 PM, Jim Allan ***@***.***> wrote:
working on updating the forks. somehow I dont have direct edit
On Thu, Aug 24, 2017 at 3:38 PM, Mike Gower ***@***.***>
wrote:
> 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.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AG_WLxRf2Z6o2gd91cuyOZZubMtpaWG-ks5sbd88gaJpZM4LB1rr>
> .
>
--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9452
<(512)%20206-9452> http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
--
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
On Thu, Aug 24, 2017 at 3:38 PM, Mike Gower ***@***.***> wrote:
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.
yes.
the note to reviewers is a not in the actual document, it is only a note to
AG reviews.
also the issue has been fixed. all content and definitions are in their
proper places.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WLxRf2Z6o2gd91cuyOZZubMtpaWG-ks5sbd88gaJpZM4LB1rr>
.
--
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
@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. |
On Thu, Aug 24, 2017 at 3:51 PM, John Foliot <notifications@github.com>
wrote:
I have one question (actually, I have a lot, but will limit it to one
here). The current text that Jim just pointed us to states:
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.*
My Question: If I apply the text adaptations noted in the Testability
Section:
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.
...and then send that content to a printer loaded with Ledger-sized paper
(11 X 17 - aka A3) in Landscape Mode, and it all prints "...with no loss of
content or adapted text properties...", then I've successfully met this SC,
correct?
is it a requirement that the page be printed on Ledger sized paper in
landscape? Did the Author say so? How is a user expected to know if the
author doesn't say so? I would expect the "average" user if they have a
printer to have 8x11 (A4) in portrait mode.
…
It won't "Pass" with
8.5 X 11 (aka A4) in Portrait mode, but currently this
SC explicitly says that paper size is not a variable in determining Success
or Failure, and so the ***@***.*** setting would be "successful".
I just want to be sure I fully understand what is being advanced forward.
JF
On Thu, Aug 24, 2017 at 3:23 PM, Jim Allan ***@***.***>
wrote:
> @GowerM
> apologies. Please use the text in the Issue
> #76
> it was forked - https://github.com/allanj-uaag/wcag21/commit/
> c2cc244 and hasn't be merged in the
> official version
>
> On Thu, Aug 24, 2017 at 2:41 PM, Mike Gower ***@***.***>
> wrote:
>
> > @emanser <https://github.com/emanser> as per my last comment,
> > <#76 (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 an 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
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#76 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-
> auth/AG_WLwPNDbfQDUcmBdkvZnFV-07T1IUGks5sbdHXgaJpZM4LB1rr>
> > .
> >
>
>
>
> --
> Jim Allan, Accessibility Coordinator
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315 <(512)%20206-9315> <(512)%20206-9315> fax:
512.206.9452 <(512)%20206-9452> <(512)%20206-9452>
> http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABK-
cw9gPJY2IZvCuVWs_b81jn_612IAks5sbdurgaJpZM4LB1rr>
> .
>
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
***@***.***
Advancing the mission of digital accessibility and inclusion
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WL2iN8lY6X89sT0NUejre8wmFaeokks5sbeJEgaJpZM4LB1rr>
.
--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9452
<(512)%20206-9452> http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
is it a requirement that the page be printed on Ledger sized paper in
landscape? Did the Author say so? How is a user expected to know if the
author doesn't say so? I would expect the "average" user if they have a
printer to have 8x11 (A4) in portrait mode.
H
i Jim,
I would expect that most content authors don't anticipate their web pages
being printed out with any kind of frequency, so I'd hardly expect
"directions" on how to print the page (with regard to paper size and
orientation), *especially* if and when the end user further modifies the
content the author initially posted (which is what the current testing
steps say to do: apply a 3rd party print style sheet that has been
helpfully noted in the SC - "
Print with the following
...
"
).
Do you have an example site that shows that kind of Help assistance?
More importantly, given that currently the SC specifically states that it
*isn't* about paper size, there is (to my mind and eyes) something of a gap
here with regard to testability, especially since the bulk of the time we
are PRINTING ON PAPER*.
Given the variety of printers and paper sizes available to the end user, it
has to be a variable that can be measured (and thus replicated) for testing
purposes, and more importantly, *DOES* have an impact on Success or Failure
testability - the
page sizes
are important parameters under which we will need to test.
Additionally, in some of the browser print dialogs I've investigated, there
is also a mechanism to adjust top, bottom and side margins... how and when
does that factor into the testing strategy? And while Header and Footer
information can be turned on and off in at least some browsers, and the
presence of that information on the page may have an impact on if or when
content 'breaks' over multiple pages, do we need to account for that as
well when "printing"?
[image: Inline image 2]
(Figure
1
: Screen capture of
the Margin adjustment feature in Firefox's Print Dialog
)
*If the intent is that page content must scale without loss when printed
at "letter" size (8.5 X 11) in Portrait mode*
* with 1/2" margins*
, then we must
explicitly
say so
(and provide *some* justification for that default testing size - for
example, why NOT also in Landscape mode? Maybe printing in Landscape Mode
*is* a technique for achieving Success for this SC?)
JF
[*OK, sometimes it will be 'printed' as a PDF for local storage... yet
another parameter undefined, as I can also set custom "page sizes" in PDF,
allowing me to "Pass" this EVERY time...]
[image: Inline image 1]
(Figure 2: Screen capture of "Oversized Pages" dialog window from PDF,
showing my custom page size of 20 inches X 30 inches)
…On Thu, Aug 24, 2017 at 4:45 PM, Jim Allan ***@***.***> wrote:
On Thu, Aug 24, 2017 at 3:51 PM, John Foliot ***@***.***>
wrote:
> I have one question (actually, I have a lot, but will limit it to one
> here). The current text that Jim just pointed us to states:
>
> 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.*
>
>
> My Question: If I apply the text adaptations noted in the Testability
> Section:
>
> 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.
>
>
> ...and then send that content to a printer loaded with Ledger-sized paper
> (11 X 17 - aka A3) in Landscape Mode, and it all prints "...with no loss
of
> content or adapted text properties...", then I've successfully met this
SC,
> correct?
>
is it a requirement that the page be printed on Ledger sized paper in
landscape? Did the Author say so? How is a user expected to know if the
author doesn't say so? I would expect the "average" user if they have a
printer to have 8x11 (A4) in portrait mode.
>
> It won't "Pass" with
>
> 8.5 X 11 (aka A4) in Portrait mode, but currently this
> SC explicitly says that paper size is not a variable in determining
Success
> or Failure, and so the ***@***.*** setting would be "successful".
>
> I just want to be sure I fully understand what is being advanced forward.
>
> JF
>
> On Thu, Aug 24, 2017 at 3:23 PM, Jim Allan ***@***.***>
> wrote:
>
> > @GowerM
> > apologies. Please use the text in the Issue
> > #76
> > it was forked - https://github.com/allanj-uaag/wcag21/commit/
> > c2cc244 and hasn't be merged in the
> > official version
> >
> > On Thu, Aug 24, 2017 at 2:41 PM, Mike Gower ***@***.***>
> > wrote:
> >
> > > @emanser <https://github.com/emanser> as per my last comment,
> > > <#76 (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 an 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
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub
> > > <#76 (comment)>, or
> > mute
> > > the thread
> > > <https://github.com/notifications/unsubscribe-
> > auth/AG_WLwPNDbfQDUcmBdkvZnFV-07T1IUGks5sbdHXgaJpZM4LB1rr>
> > > .
> > >
> >
> >
> >
> > --
> > Jim Allan, Accessibility Coordinator
> > Texas School for the Blind and Visually Impaired
> > 1100 W. 45th St., Austin, Texas 78756
> > voice 512.206.9315 <(512)%20206-9315> <(512)%20206-9315>
<(512)%20206-9315> fax:
> 512.206.9452 <(512)%20206-9452> <(512)%20206-9452> <(512)%20206-9452>
> > http://www.tsbvi.edu/
> > "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#76 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/ABK-
> cw9gPJY2IZvCuVWs_b81jn_612IAks5sbdurgaJpZM4LB1rr>
> > .
> >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> ***@***.***
>
> Advancing the mission of digital accessibility and inclusion
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AG_
WL2iN8lY6X89sT0NUejre8wmFaeokks5sbeJEgaJpZM4LB1rr>
> .
>
--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> <(512)%20206-9315> fax: 512.206.9452
<(512)%20206-9452>
<(512)%20206-9452> http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c8R3IT-7wZiNDx-0-UuQTTy6zza7ks5sbe70gaJpZM4LB1rr>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
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:
Expected Results 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 |
Hi Mike,
There are other issues that are potentially being wrapped up in this as
well, specifically related to "printing" (as opposed to just supporting
different screen sizes). The current draft text calls for:
When a page can be printed, *essential information is printed with no loss
of content* or adapted text properties.
When it comes to printing web pages, there are a number of other
significant concerns related to losing 'essential information':
- *Text hyperlinks <https://en.wikipedia.org/wiki/Hyperlink>* on a web
page, versus printing out URLs
(a good print style sheet can do this using a[href]:after{content:" ("
attr(href) ")"}, but that too has an impact on the page layout, as it
will "shift" the text to make room for the printed URL. Apparently this
already comes with some framework stylesheets
<https://drupal.stackexchange.com/questions/59900/how-to-get-rid-of-added-urls-when-printing-a-bootstrap-themed-page>,
and - sadly - more than one "tutorial
<https://processwire.com/talk/topic/9602-printing-page-in-browser-shows-urls-next-to-links/>"
on how to remove that feature exists on the web today.)
- Scrolling content inside of divs with CSS overflow:auto
<https://www.w3.org/wiki/CSS/Properties/overflow>, and/or scrolling
content inside of iFrames
(even without adapting the text, both of these scenarios would fail the
current draft language requirement)
- Images that exceed the physical dimensions of the (as yet undefined)
'default' paper page
(think infographics
<http://thumbnails.visually.netdna-cdn.com/10-corporations-control-almost-everything-you-buy_5278076859784_w1500.jpg>,
etc.)
...to name but 3 off the top of my head.
2. Print the content (using the user agent's default printer settings)
That is another part of the issue/problem: "user-agent default printer
settings" is non-specific.
Because of that, it is impossible to consistently and accurately test this.
For example (and not to pick on anybody in particular), Alastair Campbell,
being based in the UK, will be using European-sized paper (A4, A3, etc.),
while in North America, I would be using North American sizing (Letter,
Legal, Ledger). As such, he and I will have "different" default printer
settings, so when/if he and I were to test the same page, we would get
different results using
our individual
"default" settings.
That's a problem.
Additionally, some of those settings are controlled by the browser, and
while I've not done a comparison test, are we confident today that those
settings are identical across browsers and OSes? I'm certainly not, not at
this time.
Finally, at least some print dialogs also allow the end-user to
"shrink-to-fit", which *if* selected by the individual user would also skew
the test results. Is this going to be a big problem? I can't say for sure
(likely not), but the fact that it is undefined today *is* a concern, one
of many.
[image: Inline image 1]
Tech
S
pecs require just that: specified technical details. The actual physical
dimensions of the "printed page" (even allowing
for
- or not - custom pages sizes
, another unanswered, or at least unspecified, question
) will have a direct impact on measuring Success or Failure. Presumptions
and hand
-
wavey explanations aren't enough
, we need to be specific
.
Can "that" problem (specifically defining a standardized test page
dimension) be addressed by the Working Group? Absolutely! But the SC today
has nothing there, and I don't want to see us just quickly jam something in
there ad-hoc, with no research or testing, simply to get this under the
wire - that serves nobody well IMHO.
*I have repeatedly stated that I both understand the problem statement, and
I agree this is a problem we need to tackle. *
But the current proposed SC is incomplete as presented now, and we're
dealing with a deadline so that the Working Group can get 2.1 out the door.
On Tuesday, the COGA TF had to accept that a number of their proposed SC
weren't going to make the cut this round, and I for one was saddened by us
collectively having to tell the TF that, but that is our process, and we
have to keep our focus on the bigger picture as well. Sadly, I believe we
are in a similar scenario here: time has run out before we could tighten
this SC up to the point where we can confidently offer this to the wider
public review we are about to undertake.
That's not to say we relegate this to the trash-heap: far from it. We could
potentially resume working on this for WCAG 2.2, although again I am
personally of the belief that this would be most appropriately addressed by
the efforts of the Silver activity, given that there *ARE* aspects of User
Agent wrapped up in this current proposal.
However, I steadfastly oppose this moving forward today, sorry.
JF
…On Fri, Aug 25, 2017 at 8:57 AM, Mike Gower ***@***.***> wrote:
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
and help get this resolved.
There are now who-knows-how-many screen sizes and mobile form factors, yet
we have passed #78 <#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 <http://www.papersizes.org/> 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 <#78>.
------------------------------
I'll note that on that basis, I still think this SC's future is to be
subsumed by #78 <#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
<#78> with minor changes to the
language (I numbered the first line and add 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 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
<#76 (comment)>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c7ZniYLEWpywczrBWdaE4M7C-i21ks5sbtLDgaJpZM4LB1rr>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
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. |
On Thu, Aug 24, 2017 at 5:46 PM, John Foliot <notifications@github.com>
wrote:
> is it a requirement that the page be printed on Ledger sized paper in
landscape? Did the Author say so? How is a user expected to know if the
author doesn't say so? I would expect the "average" user if they have a
printer to have 8x11 (A4) in portrait mode.
H
i Jim,
I would expect that most content authors don't anticipate their web pages
being printed out with any kind of frequency, so I'd hardly expect
"directions" on how to print the page (with regard to paper size and
orientation), *especially* if and when the end user further modifies the
content the author initially posted (which is what the current testing
steps say to do: apply a 3rd party print style sheet that has been
helpfully noted in the SC - "
Print with the following
on the flip side, would an author expect anything other that 8x11 (a4)
paper.
...
"
).
Do you have an example site that shows that kind of Help assistance?
the layout of braille files can be single or double sided, and on 8.5x11
or 11x11.5 paper. It is difficult to know from looking at a braille file
how it will print. so...
http://www.tsbvi.edu/braille-resources/1978-braille-book-files
- Files are single-sided; there are no known interpoint files.
- Unless otherwise noted, the files for download are contracted (grade
2) braille. Do not translate; these files are already translated and ready
to print on a braille embossser - 40 characters per line."
More importantly, given that currently the SC specifically states that it
*isn't* about paper size, there is (to my mind and eyes) something of a gap
here with regard to testability, especially since the bulk of the time we
are PRINTING ON PAPER*.
the browser handles the breakpoints for paper sizes. IF the author uses
responsive measurements (%) all is fine. in sites that truncate text I
found the author used px widths.
Given the variety of printers and paper sizes available to the end user, it
has to be a variable that can be measured (and thus replicated) for testing
purposes, and more importantly, *DOES* have an impact on Success or Failure
testability - the
page sizes
are important parameters under which we will need to test.
We could add a not that you only need to text on "standard" paper 8.5x11
(A4) in Portrait
would that satisfy? http://www.papersizes.org/
Additionally, in some of the browser print dialogs I've investigated, there
is also a mechanism to adjust top, bottom and side margins... how and when
does that factor into the testing strategy? And while Header and Footer
information can be turned on and off in at least some browsers, and the
presence of that information on the page may have an impact on if or when
content 'breaks' over multiple pages, do we need to account for that as
well when "printing"?
[image: Inline image 2]
(Figure
1
: Screen capture of
the Margin adjustment feature in Firefox's Print Dialog
)
again... if the author used *responsive measurements*, the browser
adjusts the printable content area accordingly and the content flows to
available allowable space ... paper size, margins, portrait/landscape
taken into account.
*If the intent is that page content must scale without loss when printed
… at "letter" size (8.5 X 11) in Portrait mode*
* with 1/2" margins*
, then we must
explicitly
say so
(and provide *some* justification for that default testing size - for
example, why NOT also in Landscape mode? Maybe printing in Landscape Mode
*is* a technique for achieving Success for this SC?)
JF
[*OK, sometimes it will be 'printed' as a PDF for local storage... yet
another parameter undefined, as I can also set custom "page sizes" in PDF,
allowing me to "Pass" this EVERY time...]
[image: Inline image 1]
(Figure 2: Screen capture of "Oversized Pages" dialog window from PDF,
showing my custom page size of 20 inches X 30 inches)
On Thu, Aug 24, 2017 at 4:45 PM, Jim Allan ***@***.***>
wrote:
> On Thu, Aug 24, 2017 at 3:51 PM, John Foliot ***@***.***>
> wrote:
>
> > I have one question (actually, I have a lot, but will limit it to one
> > here). The current text that Jim just pointed us to states:
> >
> > 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.*
> >
> >
> > My Question: If I apply the text adaptations noted in the Testability
> > Section:
> >
> > 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.
> >
> >
> > ...and then send that content to a printer loaded with Ledger-sized
paper
> > (11 X 17 - aka A3) in Landscape Mode, and it all prints "...with no
loss
> of
> > content or adapted text properties...", then I've successfully met this
> SC,
> > correct?
> >
>
> is it a requirement that the page be printed on Ledger sized paper in
> landscape? Did the Author say so? How is a user expected to know if the
> author doesn't say so? I would expect the "average" user if they have a
> printer to have 8x11 (A4) in portrait mode.
>
> >
> > It won't "Pass" with
> >
> > 8.5 X 11 (aka A4) in Portrait mode, but currently this
> > SC explicitly says that paper size is not a variable in determining
> Success
> > or Failure, and so the ***@***.*** setting would be "successful".
> >
> > I just want to be sure I fully understand what is being advanced
forward.
> >
> > JF
> >
> > On Thu, Aug 24, 2017 at 3:23 PM, Jim Allan ***@***.***>
> > wrote:
> >
> > > @GowerM
> > > apologies. Please use the text in the Issue
> > > #76
> > > it was forked - https://github.com/allanj-uaag/wcag21/commit/
> > > c2cc244 and hasn't be merged in the
> > > official version
> > >
> > > On Thu, Aug 24, 2017 at 2:41 PM, Mike Gower <
***@***.***>
> > > wrote:
> > >
> > > > @emanser <https://github.com/emanser> as per my last comment,
> > > > <#76 (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 an 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
> > > >
> > > > —
> > > > You are receiving this because you were mentioned.
> > > > Reply to this email directly, view it on GitHub
> > > > <#76 (comment)>,
or
> > > mute
> > > > the thread
> > > > <https://github.com/notifications/unsubscribe-
> > > auth/AG_WLwPNDbfQDUcmBdkvZnFV-07T1IUGks5sbdHXgaJpZM4LB1rr>
> > > > .
> > > >
> > >
> > >
> > >
> > > --
> > > Jim Allan, Accessibility Coordinator
> > > Texas School for the Blind and Visually Impaired
> > > 1100 W. 45th St., Austin, Texas 78756
> > > voice 512.206.9315 <%28512%29%20206-9315> <(512)%20206-9315>
<(512)%20206-9315>
> <(512)%20206-9315> fax:
> > 512.206.9452 <%28512%29%20206-9452> <(512)%20206-9452>
<(512)%20206-9452> <(512)%20206-9452>
> > > http://www.tsbvi.edu/
> > > "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub
> > > <#76 (comment)>, or
> > mute
> > > the thread
> > > <https://github.com/notifications/unsubscribe-auth/ABK-
> > cw9gPJY2IZvCuVWs_b81jn_612IAks5sbdurgaJpZM4LB1rr>
> > > .
> > >
> >
> >
> >
> > --
> > John Foliot
> > Principal Accessibility Strategist
> > Deque Systems Inc.
> > ***@***.***
> >
> > Advancing the mission of digital accessibility and inclusion
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#76 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/AG_
> WL2iN8lY6X89sT0NUejre8wmFaeokks5sbeJEgaJpZM4LB1rr>
> > .
> >
>
>
>
> --
> Jim Allan, Accessibility Coordinator
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315 <%28512%29%20206-9315> <(512)%20206-9315>
<(512)%20206-9315> fax: 512.206.9452 <%28512%29%20206-9452>
> <(512)%20206-9452>
> <(512)%20206-9452> http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABK-c8R3IT-7wZiNDx-0-
UuQTTy6zza7ks5sbe70gaJpZM4LB1rr>
> .
>
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
***@***.***
Advancing the mission of digital accessibility and inclusion
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WL7weSrZ5qo6N-VQZxE8Ig9EBK83Kks5sbf1YgaJpZM4LB1rr>
.
--
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|
Hi Jim
on the flip side, would an author expect anything other that 8x11 (a4)
paper.
I don't know... in a technical specification I don't want to assume
anything, and I really don't know what any given page author would expect.
Do you? (I mean, is it reasonable to also assume Legal sized paper? I
suspect pretty much everyone reading this has, or has access to, paper of
that size in their printers as well)
> the browser handles the breakpoints for paper sizes. IF the author uses
responsive measurements (%) all is fine. in sites that truncate text I
found the author used px widths.
So then, what is *really* being sought out is not so much an ability to
print, but rather, to facilitate printing at different text-settings,
content authors MUST NOT use fixed widths in layout measurements. (I note
at this time that we're now discussing layouts, and not text adaptations,
which would have an impact on layout, but is not specifically addressed in
this SC - it's the layouts that are broken, not the text adaptation bit.)
If that is the case, then this might be a "Robustness" (SC 4.X.X) issue,
and less of a "Perception" (SC1.X.X) issue - although that is wandering off
into the weeds.
Part of my concern however is that this SC is explicitly mandating an NEED
to Print-out the content (which is unusual anyway, although I understand
the need), and in fact specifically states that is how to do the testing,
and so as part of the "printing" we need to clearly and definitively
declare what the print parameters are, so that they can be universally
tested.
I currently don't know if all browsers will use the same page-breaks on
identical HTML content, and as I've already pointed out, 'defaults' can be
changed (knowingly or accidentally) in a) the browser, or b) the Printer
Properties settings, and so at a minimum we need to define what we mean by
"default" in all of its aspects.
We could add a not that you only need to text on "standard" paper 8.5x11 (A4)
in Portrait
would that satisfy? http://www.papersizes.org/
That would certainly address a part of my concern, yes. (I'd also want to
ensure that margins are explicitly called out too, as in at least Firefox I
can adjust those as well)
again... if the author used *responsive measurements*, the browser
adjusts the printable content area accordingly and the content flows to
available allowable space ... paper size, margins, portrait/landscape
taken into account.
.
..and yet, nothing in the current Draft SC gets to the nut of that
requirement.
Perhaps that needs to be addressed in the Understanding documentation, but
it seems to me a pretty significant requirement it the only way to meet
this current 'ask' is to demand ONLY responsive measurements in your layout
containers. Off the top, I'm not philosophically opposed to that, but we'd
likely want to think that through a bit more. ("Rushing" things serves
no-one well)
Jim, there are however other concerns related to "Printing" that I also
mentioned, including losing URLs that are only embedded in text links,
scrollable content in fixed containers, and oversized graphics (and
possibly other issues too, I'm thinking off the top of my head here). These
would all be losses of either content or context even if the text
adaptations *were not* applied, and so in attempting to meet a specific
need, I fear the net has been cast too widely, or without enough thought as
to what all of it really means.
I've repeatedly stated I would like to see us continue with this, but not
as part of the 2.1 slate of SCs - it's just too immature at this time.
We've run out of time, and that's a shame, but we have to keep moving with
the process we have.
JF
On Fri, Aug 25, 2017 at 12:39 PM, Jim Allan <notifications@github.com>
wrote:
… On Thu, Aug 24, 2017 at 5:46 PM, John Foliot ***@***.***>
wrote:
> > is it a requirement that the page be printed on Ledger sized paper in
> landscape? Did the Author say so? How is a user expected to know if the
> author doesn't say so? I would expect the "average" user if they have a
> printer to have 8x11 (A4) in portrait mode.
>
>
> H
> i Jim,
>
> I would expect that most content authors don't anticipate their web pages
> being printed out with any kind of frequency, so I'd hardly expect
> "directions" on how to print the page (with regard to paper size and
> orientation), *especially* if and when the end user further modifies the
> content the author initially posted (which is what the current testing
> steps say to do: apply a 3rd party print style sheet that has been
> helpfully noted in the SC - "
> Print with the following
>
on the flip side, would an author expect anything other that 8x11 (a4)
paper.
...
> "
> ).
> Do you have an example site that shows that kind of Help assistance?
>
>
the layout of braille files can be single or double sided, and on 8.5x11
or 11x11.5 paper. It is difficult to know from looking at a braille file
how it will print. so...
http://www.tsbvi.edu/braille-resources/1978-braille-book-files
- Files are single-sided; there are no known interpoint files.
- Unless otherwise noted, the files for download are contracted (grade
2) braille. Do not translate; these files are already translated and ready
to print on a braille embossser - 40 characters per line."
>
> More importantly, given that currently the SC specifically states that it
> *isn't* about paper size, there is (to my mind and eyes) something of a
gap
> here with regard to testability, especially since the bulk of the time we
> are PRINTING ON PAPER*.
>
the browser handles the breakpoints for paper sizes. IF the author uses
responsive measurements (%) all is fine. in sites that truncate text I
found the author used px widths.
>
> Given the variety of printers and paper sizes available to the end user,
it
> has to be a variable that can be measured (and thus replicated) for
testing
> purposes, and more importantly, *DOES* have an impact on Success or
Failure
> testability - the
> page sizes
> are important parameters under which we will need to test.
>
We could add a not that you only need to text on "standard" paper 8.5x11
(A4) in Portrait
would that satisfy? http://www.papersizes.org/
>
> Additionally, in some of the browser print dialogs I've investigated,
there
> is also a mechanism to adjust top, bottom and side margins... how and
when
> does that factor into the testing strategy? And while Header and Footer
> information can be turned on and off in at least some browsers, and the
> presence of that information on the page may have an impact on if or when
> content 'breaks' over multiple pages, do we need to account for that as
> well when "printing"?
>
> [image: Inline image 2]
> (Figure
> 1
> : Screen capture of
> the Margin adjustment feature in Firefox's Print Dialog
> )
>
>
> again... if the author used *responsive measurements*, the browser
adjusts the printable content area accordingly and the content flows to
available allowable space ... paper size, margins, portrait/landscape
taken into account.
*If the intent is that page content must scale without loss when printed
> at "letter" size (8.5 X 11) in Portrait mode*
> * with 1/2" margins*
> , then we must
> explicitly
> say so
> (and provide *some* justification for that default testing size - for
> example, why NOT also in Landscape mode? Maybe printing in Landscape Mode
> *is* a technique for achieving Success for this SC?)
>
>
>
> JF
>
> [*OK, sometimes it will be 'printed' as a PDF for local storage... yet
> another parameter undefined, as I can also set custom "page sizes" in
PDF,
> allowing me to "Pass" this EVERY time...]
>
> [image: Inline image 1]
> (Figure 2: Screen capture of "Oversized Pages" dialog window from PDF,
> showing my custom page size of 20 inches X 30 inches)
>
>
>
>
>
> On Thu, Aug 24, 2017 at 4:45 PM, Jim Allan ***@***.***>
> wrote:
>
> > On Thu, Aug 24, 2017 at 3:51 PM, John Foliot ***@***.***
>
> > wrote:
> >
> > > I have one question (actually, I have a lot, but will limit it to one
> > > here). The current text that Jim just pointed us to states:
> > >
> > > 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.*
> > >
> > >
> > > My Question: If I apply the text adaptations noted in the Testability
> > > Section:
> > >
> > > 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.
> > >
> > >
> > > ...and then send that content to a printer loaded with Ledger-sized
> paper
> > > (11 X 17 - aka A3) in Landscape Mode, and it all prints "...with no
> loss
> > of
> > > content or adapted text properties...", then I've successfully met
this
> > SC,
> > > correct?
> > >
> >
> > is it a requirement that the page be printed on Ledger sized paper in
> > landscape? Did the Author say so? How is a user expected to know if the
> > author doesn't say so? I would expect the "average" user if they have a
> > printer to have 8x11 (A4) in portrait mode.
> >
> > >
> > > It won't "Pass" with
> > >
> > > 8.5 X 11 (aka A4) in Portrait mode, but currently this
> > > SC explicitly says that paper size is not a variable in determining
> > Success
> > > or Failure, and so the ***@***.*** setting would be
"successful".
> > >
> > > I just want to be sure I fully understand what is being advanced
> forward.
> > >
> > > JF
> > >
> > > On Thu, Aug 24, 2017 at 3:23 PM, Jim Allan ***@***.***
>
> > > wrote:
> > >
> > > > @GowerM
> > > > apologies. Please use the text in the Issue
> > > > #76
> > > > it was forked - https://github.com/allanj-uaag/wcag21/commit/
> > > > c2cc244 and hasn't be merged in
the
> > > > official version
> > > >
> > > > On Thu, Aug 24, 2017 at 2:41 PM, Mike Gower <
> ***@***.***>
> > > > wrote:
> > > >
> > > > > @emanser <https://github.com/emanser> as per my last comment,
> > > > > <#76 (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 an 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
> > > > >
> > > > > —
> > > > > You are receiving this because you were mentioned.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <#76 (comment)
>,
> or
> > > > mute
> > > > > the thread
> > > > > <https://github.com/notifications/unsubscribe-
> > > > auth/AG_WLwPNDbfQDUcmBdkvZnFV-07T1IUGks5sbdHXgaJpZM4LB1rr>
> > > > > .
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jim Allan, Accessibility Coordinator
> > > > Texas School for the Blind and Visually Impaired
> > > > 1100 W. 45th St., Austin, Texas 78756
> > > > voice 512.206.9315 <(512)%20206-9315> <%28512%29%20206-9315>
<(512)%20206-9315>
> <(512)%20206-9315>
> > <(512)%20206-9315> fax:
> > > 512.206.9452 <(512)%20206-9452> <%28512%29%20206-9452>
<(512)%20206-9452>
> <(512)%20206-9452> <(512)%20206-9452>
> > > > http://www.tsbvi.edu/
> > > > "We shape our tools and thereafter our tools shape us." McLuhan,
1964
> > > >
> > > > —
> > > > You are receiving this because you were mentioned.
> > > > Reply to this email directly, view it on GitHub
> > > > <#76 (comment)>,
or
> > > mute
> > > > the thread
> > > > <https://github.com/notifications/unsubscribe-auth/ABK-
> > > cw9gPJY2IZvCuVWs_b81jn_612IAks5sbdurgaJpZM4LB1rr>
> > > > .
> > > >
> > >
> > >
> > >
> > > --
> > > John Foliot
> > > Principal Accessibility Strategist
> > > Deque Systems Inc.
> > > ***@***.***
> > >
> > > Advancing the mission of digital accessibility and inclusion
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub
> > > <#76 (comment)>, or
> > mute
> > > the thread
> > > <https://github.com/notifications/unsubscribe-auth/AG_
> > WL2iN8lY6X89sT0NUejre8wmFaeokks5sbeJEgaJpZM4LB1rr>
> > > .
> > >
> >
> >
> >
> > --
> > Jim Allan, Accessibility Coordinator
> > Texas School for the Blind and Visually Impaired
> > 1100 W. 45th St., Austin, Texas 78756
> > voice 512.206.9315 <(512)%20206-9315> <%28512%29%20206-9315>
<(512)%20206-9315>
> <(512)%20206-9315> fax: 512.206.9452 <(512)%20206-9452>
<%28512%29%20206-9452>
> > <(512)%20206-9452>
> > <(512)%20206-9452> http://www.tsbvi.edu/
> > "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#76 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-
auth/ABK-c8R3IT-7wZiNDx-0-
> UuQTTy6zza7ks5sbe70gaJpZM4LB1rr>
>
> > .
> >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> ***@***.***
>
> Advancing the mission of digital accessibility and inclusion
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#76 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AG_WL7weSrZ5qo6N-
VQZxE8Ig9EBK83Kks5sbf1YgaJpZM4LB1rr>
> .
>
--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9452 <(512)%20206-9452>
http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c3CFw-dv-1AkJLj9k0c6f6_DdNzlks5sbwa4gaJpZM4LB1rr>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
Did not reach consensus, so deferring |
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
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:
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
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
New Techniques
Related Information
The text was updated successfully, but these errors were encountered: