This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
What is sufficient for SC 1.4.10? (PDF) #814
Comments
|
My personal understanding/take on this would be that 1.4.10 essentially relies on the user agent (in this case, the PDF reader) being actually able to reflow/having that capability, and then to satisfy the requirement the content should not actively try to prevent the user agent from performing the reflow. Long story short: if the content does reflow when the reader is set to reflow (as it's not its standard behavior for PDFs), then the SC is met. (I'll leave aside my usual concern that, to me, PDF isn't really "web content" when we start talking about it being opened in a separate reader...) |
|
Hello Kerstin,
You should check if the document reflows well up to 400%. You don't have to
worry about images or tables.
There is one thing that goes wrong with PDF documents that are generated by
a program frequently. The generator program may not actually use space
characters for space between words. LaTex documents often have this problem
when exported to PDF. For example the first line of this paragraph may
look like this:
Thereisone thing thatgoes wrong with PDFdocumentsthat are
This is not readable. I you zoom with reflow your file and it looks like
words are mashed together, it fails the user.
One way to address this problem is to make one file for mobile phone and
one for laptop / desktop.
Best, Wayne
…On Wed, Jul 3, 2019 at 11:37 PM Patrick H. Lauke ***@***.***> wrote:
My personal understanding/take on this would be that 1.4.10 essentially
relies on the user agent (in this case, the PDF reader) being actually able
to reflow/having that capability, and then to satisfy the requirement the
content should not actively try to prevent the user agent from performing
the reflow. Long story short: if the content does reflow when the reader is
set to reflow (as it's not its standard behavior for PDFs), then the SC is
met.
(I'll leave aside my usual concern that, to me, PDF isn't really "web
content" when we start talking about it being opened in a separate
reader...)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#814?email_source=notifications&email_token=AB6Q4FYRJTILVLXO64KIYDTP5WLDDA5CNFSM4H5TV642YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZGPARA#issuecomment-508358724>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F3X3BL4MYWOBG3HI53P5WLDDANCNFSM4H5TV64Q>
.
|
|
Thanks. Seems a misunderstanding happened. My question was not how to realize Adobe Reflow but wether a realized Adobe Reflow is sufficient and one way / option for claiming conformance with SC 1.4.10? Best, Kerstin |
|
Dear Kerstin,
I think you missed a subtlety. The user agent can be an agent to meet
1.4.10 but it is neither necessary nor sufficient to rely on the user
agent. The example I gave of words running together on PDF zoom is a
frequently occuring, chronic problem with PDF. It is content based, and if
it occurs in the content then zoom cannot fix it. The content fails.
Also, the author need not rely on the user agent to achieve reflow at width
320 px. One can reformat the a copy document to fit 320 px and that would
meet 1.4.10.
There are many ways a user agent can achieve reflow and still fail 1.4.10.
So the answer is that user agent zoom is neither necessary nor sufficient
to meet this requirement.
Best, Wayne
…On Sat, Jul 13, 2019 at 12:29 AM Kerstin Probiesch ***@***.***> wrote:
@WayneEDick <https://github.com/WayneEDick>
Thanks. Seems a misunderstanding happened. My question was not how to
realize Adobe Reflow but wether a realized Adobe Reflow is sufficient and
one way / option for claiming conformance with SC 1.4.10?
Best,
Kerstin
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#814?email_source=notifications&email_token=AB6Q4F2EDS2DNQXWOP7JNZ3P7F74NA5CNFSM4H5TV642YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3LZJY#issuecomment-511098023>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4FYHJG633XPJ6TYJ2MDP7F74NANCNFSM4H5TV64Q>
.
|
|
so to be clear then...how exactly can you determine/test if a PDF passes or fails 1.4.10? and what are the techniques for authors to ensure their PDFs pass 1.4.10? are authors expected to create separate PDFs, one of which is adapted to work at 320 CSS px width? [edit: scratch the extra point i made about potential loophole...zooming out would obviously - in web browsers - change the CSS px size away from 320 CSS px, and the same conceptually probably happens for PDFs] |
|
We do need techniques for PDF explicitly. I agree. Like HTML which does
allow functional mobile documents to be used, one solution may be second
formattings that fit mobile. Of course, I do recognize that approach
creates a maintenance problem. That would not be the best solution, but it
is a solution.
This weekend I was reading a multivariate calculus in an eBook to help one
of my neighborhood young adults, that book word wrapped nicely up to 400%.
Reflow can be done even with complex content. (Note: Prior to 1.4.10, I
could find no college level Calculus, Physics or Chemistry books that
reflowed. Now there are a handful.)
The best solution is to design documents so that they reflow in the PDF
media player. I guess the best way to test that is put the zoom to 400%
with width set 1280px on your device, and see if reflow works. Things to
look for are words mashed together (a frequent problem), and situations
where the content ignores 400% zoom.
Finally, a little lesson on how people with low vision read PDF:
You bring in the file at normal resolution. You try reflow first, but that
usually fails to work due to mashed words. Next you enlarge to the maximum
point that will not run off the screen. If possible you move the screen
close enough to your face to read. For me that is 4 inches. Otherwise you
enlarge to the point you can see, but require scrolling.
It should be noted that PDF file that is formatted to fit 320px with
reflow, would allow 400% zoom at 1280 px without viewport overflow. Thus,
multiple formats would work, though the maintenance issue would be a
problem. This is how users read multi-column formats routinely.
It has been my experience that PDF documents tend to change less frequently
than HTML. Thus, maintenance may be less critical.
The most difficult PDF documents to reformat are forms. I believe we could
look at exception in that case (much like the table or image case).
Instructions and legal disclaimers would have to reflow but the actual
input sections could likely scroll horizontally. That would need a
technique.
Like many users, I use a screen reader for forms, but we cannot count on
screen reader use. After all, there are people with low vision who are hard
of hearing or deaf.
Finally, many PDF files are made to present text that is meant for reading.
They are read only documents with a lot of text to read. Without proper
enlargement with word wrapping that works, these documents are unreadable.
These documents include institutional policies, health insurance
information, drug instructions, user guides for devices and software, legal
opinions, scientific expositions and essays. The primary function of these
documents is to be read. Failure to word wrap should be a failure for these
documents.
Conformance and testing do not appear to be odious.
…On Sun, Jul 14, 2019 at 3:35 PM Patrick H. Lauke ***@***.***> wrote:
so to be clear then...how exactly can you determine/test if a PDF passes
or fails 1.4.10? and what are the techniques for authors to ensure their
PDFs pass 1.4.10?
are authors expected to create separate PDFs, one of which is adapted to
work at 320 CSS px width?
further, 1.4.10 on its own only really talks about not having any
horizontal+vertical scrolling. it says nothing about what size the actual
page/document is displayed at. if a PDF is opened on a 320 CSS px wide
screen/window, and by default the PDF is zoomed out so that it all
fits...does this pass 1.4.10? i don't see anything normative that says it
doesn't.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#814?email_source=notifications&email_token=AB6Q4FZFHVIMQWDLKZMTTGDP7OSZ3A5CNFSM4H5TV642YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4OVVY#issuecomment-511240919>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F7OGY3E25E2MJX6ZQTP7OSZ3ANCNFSM4H5TV64Q>
.
|
but was that ebook in PDF format? if it was an ebook which under the hood is really just HTML/CSS, then yes, the whole reflowing is baked into how HTML is handled. can you do the same with a PDF and tell it to reflow? i'm no expert, but am under the impression that PDF readers simply don't do the reflow, and that PDF documents out of the box have no concept of this reflowing/adapting ... which would suggest to me more that this SC is not applicable directly to PDF in any way other than "create a special separate version of your PDF where you limit yourself to a particular dimension" (and I think the concept of CSS px would also need to be interpreted/adapted for PDF, as i don't think PDF measures are based on pixels but rather mimic physical print measures? |
|
PDF does have a reflow option but it seems to pull content from the content panel and I’m not exactly sure how it works Forms and tables can’t be reflowed. |
to be more precise, adobe's PDF reader has a reflow option. this is not something intrinsic to the way PDFs are handled, but rather an option present in that particular reader? and note that wayne initially said that it should work without requiring the user to select this reflow option, which doesn't seem possible (as by default, when you zoom into a PDF to enlarge its content, it invariably will maintain layout as is and just zoom, resulting in scrollbars). long story short: PDF as a format does not seem to have a concept of reflowing content to adapt to the viewport, the same way that HTML has. it also has no concept of "CSS pixels", as its units of measure are all based on typographic measures (so likely "points"). it seems the only way to satisfy this criterion is to create a separate "narrow/small format" version of every PDF, OR to say "it must work when reflow is enabled in adobe's PDF reader" which apparently has lots of weird quirks, as it effectively munges the PDF to try and force the reflow, and it's not something that can easily be prepped for/foreseen by authors. OR we exempt PDFs from the SC? |
for instance, if i open a PDF directly in Chrome (with its built-in PDF reader), there is no reflow option, and there's no way for me as a user to force reflowing...zooming/enlarging will simply zoom the set layout, resulting in scrollbars, and there's nothing the PDF author can do about this other than try and craft some custom PDF for very small artboard/document size with very large text. so to me this feels very much like the SC is not applicable directly to PDF as a technology (the same way it also wouldn't be applicable to, say, embedded flash or silverlight or whatever content). either it's N/A, or an automatic FAIL unless authors provided a second version that does work at that very specific size. |
|
I agree with Patrick. In the case that the PDF user agent does not allow
reflow the SC is a N/A.
The point is does the content reflow correctly with a user agent that does
support reflow. There are many. A user with low vision who finds a UA that
does support reflow should be able to get it.
Best, Wayne
…On Tue, Jul 16, 2019 at 12:22 AM Patrick H. Lauke ***@***.***> wrote:
to be more precise, adobe's PDF reader has a reflow option. this is not
something intrinsic to the way PDFs are handled, but rather an option
present in that particular reader?
for instance, if i open a PDF directly in Chrome (with its built-in PDF
reader), there is no reflow option, and there's no way for me as a user to
force reflowing...zooming/enlarging will simply zoom the set layout,
resulting in scrollbars, and there's nothing the PDF author can do about
this other than try and craft some custom PDF for very small
artboard/document size with very large text.
so to me this feels very much like the SC is not applicable directly to
PDF as a technology (the same way it also wouldn't be applicable to, say,
embedded flash or silverlight or whatever content). either it's N/A, or an
automatic FAIL unless authors provided a second version that does work at
that very specific size.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#814?email_source=notifications&email_token=AB6Q4F37VIP5CZS5667AQLLP7VZMVA5CNFSM4H5TV642YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ76MRI#issuecomment-511698501>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F2I5QDAWCVI5ZPGZCDP7VZMVANCNFSM4H5TV64Q>
.
|
So how do you square this in actual testing then?
Looking at browsers (since, in fairness, that's what we need to consider primarily when looking at WEB content accessibility guidelines ... having PDFs downloaded and run in a standalone PDF viewer isn't web content anymore as the file has been downloaded locally and then opened locally), Chrome, Firefox, Edge have built-in PDF viewing, and none of these have any kind of reflow mode. I'd posit that most people view PDFs with the built-in viewers nowadays. So the only other applicable situation would be things like PDF extensions/plugins for browsers like Adobe Reader, which do. My concern then is that the requirement on authors, and evaluation need when auditing, is down to whether or not a PDF adapt correctly to a proprietary feature in a single (?) product - I say proprietary here, because reflow isn't, to my knowledge, part of anything standardised in PDF, and it's really just the way Adobe's reader munges and reformats (with its own secret sauce algorithms?) a PDF to try and force a reflow. So overall, I'm quite uncomfortable with this entire SC hinging, in the case of PDF, on basically "does it work in Adobe Reader plugin". (There may be other, lesser known PDF plugins/extensions for browsers ... happy to hear about more, and whether or not they have that ability) |
|
And, to be clear, this is the crux of some of @KerstinP's questions - is WCAG 2.1 as a standard simply reifying "must be made in / must work with Adobe products" when it comes to PDF? |
|
That is a good question. I do test in Acrobat, and read in Acrobat. As far
as PDF production goes, I do not know. I know that the PDF made by many
LaTex processors will fail because of the justification algorithm used.
What I do know is that you can use Adobe products that produce WCAG 2.0
conformant documents that fail reflow. So, the problem is with the content
not the player.
…On Fri, Jul 19, 2019 at 12:52 AM Patrick H. Lauke ***@***.***> wrote:
And, to be clear, this is the crux of some of @KerstinP
<https://github.com/kerstinp>'s questions - is WCAG 2.1 as a standard
simply reifying "most be made in / must work with Adobe products" when it
comes to PDF?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#814?email_source=notifications&email_token=AB6Q4FYZWOO6KJALMXXO2KDQAFXELA5CNFSM4H5TV642YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2K4HTI#issuecomment-513131469>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F5WKA6FYSELI2CUX4DQAFXELANCNFSM4H5TV64Q>
.
|
|
to me then, this feels very much like a problem of "Adobe's own proprietary reflow algorithm, where it actively ignores dimensions etc defined in the PDF to try and reflow content not actually meant to reflow, sometimes fails". this is distinctly different from the situation of HTML reflowing, where browsers follow fairly well specified and standardised CSS layout algorithms. for this reason, i'd tend towards explicitly making 1.4.10 not applicable to PDFs, as the PDF format itself does not currently have any concept of responsiveness or reflow. it could be advised that where PDFs are used, authors should consider not using PDF and instead use a format like HTML that is designed to actually adapt/reflow in a standardised way, OR to produce secondary PDFs that work well at smaller widths. but tying the pass/fail to a "Adobe's secret algorithm manages to reflow it correctly" seems a bit more flimsy. |
|
(and as a side note, if by "I do test in Acrobat" you meant the standalone Acrobat Reader application, rather than the browser plugin, then that falls outside of being "web content" at that point) |
|
This of course gets to the real problem. Is PDF suitable for informative
documents, policy documents or instructional materials. Without reflow
probably not.
I would not like to say that. It could be a user agent problem, but in
truth if you cannot enlarge a document without 2-dimensional scrolling it
is inaccessible to anyone classified with a low vision disability. We
proved that incontrovertibly last year.
I would say do this: Download the document to a computer. Run a PDF player
that supports reflow. If your document is readable after reflow at
enlargement of 400% pass your document. Otherwise, fail it.
Why is this correct. The process of download technology and use of a
reflowable PDF constitutes an assistive technology for reflowable access.
You do not have to use a web based assistive technology to transform web
content. This is why the assistive technology definition describes
assistive technology as a user agents that, "...provides services beyond
those offered by the host user agents to meet the requirements of users
with disabilities. Additional services include alternative renderings
(e.g., as synthesized speech or magnified content)"...
In this case the combination of the download API and platform based PDF
reader is the user agent that provides magnified content in a usable format.
People need to open their minds to the fact that no formal AT exists for
low vision that produces accessible enlargement. Screen Magnifiers don't
produce accessible displays. Screen readers are good as far as they go, but
they are do not provide a self paced medium for low vision as they do for
users who are blind, namely refreshable braille.
The combination I define is a viable AT for accessible PDF. You don't have
to read it on the web for it to be web content.
I never read the LA Times online. I always download articles, transform
them and read them from my own local server. That is my AT and I consider
the LA times accessible because I can do that.
Would it better if users with low vision had dedicated AT, but we don't. Do
we get no help using non-traditional AT, or do authors get a free ride for
not providing accessible content that we could read with standard software
used as AT.
…On Fri, Jul 19, 2019 at 4:53 PM Patrick H. Lauke ***@***.***> wrote:
(and as a side note, if by "I do test in Acrobat" you meant the standalone
Acrobat Reader application, rather than the browser plugin, then that falls
outside of being "web content" at that point)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#814?email_source=notifications&email_token=AB6Q4F2QTFMDC752WHXVQWTQAJHYJA5CNFSM4H5TV642YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NBIUA#issuecomment-513414224>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4FZR35MWXOEEPJ7G373QAJHYJANCNFSM4H5TV64Q>
.
|
|
sorry wayne, but i strongly disagree with the assertion that using a standalone application on a locally downloaded version of a document is a good test for web content, since it's not web content at that stage per the definition. because at it's not assistive technology that sits on top of your web browser, but something completely separate from it. i'm not disputing that it's a problem for low vision users when PDFs don't reflow, but what i'm saying is that it's simply not part of the PDF technology itself to support reflow. Acrobat has its own proprietary magic to butcher a PDF to make it fit, but that's not part of the PDF standard. this would be akin to saying "if it doesn't use some proprietary quirk of JAWS, the page is not accessible". we're not "blessing" any particular AT with this kind of statement, so why do it for a proprietary feature of Adobe Acrobat? |
|
@patrickhlauke I don't disagree that the reflowing is handled by the user agent, but it is definitely part of the spec (see 14.8.1 in https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf). PDF is very similar to HTML in that the spec isn't what makes reflow happen, it is the user agent. |
|
interesting, i stand corrected on the "not part of the spec" aspect. and yes, agree that of course it's the user agent that needs to handle it, but was unaware that it's actually defined directly in the PDF spec and is not just something that Acrobat takes upon itself to munge/ignore dimensions/etc. circling back then - what are the sufficient techniques for authors to use? is there a "correct" way of generating PDFs, or is it a case of "test if Acrobat can reflow it, otherwise...try things until it does"? |
|
Other programs VIPreader reflow pdf docs as well. |
is it available as a browser plugin, or standalone application. As again, once a PDF is downloaded and then opened in a standalone app ... it's arguably not "web content" anymore...but fair enough, if we're just talking about testing, we may then have to live with that approximation (along the lines of "if the PDF readers in browsers supported this option as well, then it would reflow correctly there too"). In any case, as reflow does appear to be standard feature of the PDF format (rather than a completely proprietary Adobe document-munging technique), I retract the "it's N/A for PDF"...though unfortunate if there's no (or only very limited) in-browser solutions that do actually allow reflow. Would be good to jot some of these things down in the understanding doc as a note specifically regarding PDFs |
|
So, working from the above, the current situation appears to be:
So it would seem that opening a PDF in Acrobat, resizing the window to 320px wide (not including scroll bar) and reflowing would be a reasonable test method. |
|
looking at this a bit more, i think there's still some odd nuance here compared to reflowability of HTML... it seems that what VIPreader does is to open a PDF and then suck out the content from it and reformat it. so it's something that changes what's fundamentally being displayed (arguably, it's not displaying the PDF, but its own reinterpretation of the content it found in the PDF?) as for the PDF spec including reflow, it seems it's more about defining the content order correctly so that if a reader does some reflowing, it'll work...but the actual way in which content gets reflowed is not part of the spec per se. so...still feels a bit ambiguous to me here... |
so to clarify...VIPreader is likely not a good tool to determine "reflow" of a PDF, since it does its own completely own layout of the pure content it finds in a PDF. it's like me writing some scraping tool that reads a site's pure HTML content and redisplays that...it won't let me make any determination about whether or not the original site is ok or not. the only thing that would result in something in VIPreader not working correctly is if the content order inside the PDF was not defined correctly...which is not the point of 1.4.10 ? |
|
There is a whole category of issues where the text doesn’t come out as you’d expect, I think Wayne commented above (or elsewhere recently) that often thewordsruntogether... or they’re encode as images and come out strangely. You might consider that orthagonal to reflow, however, it appears when you use any feature (VIPreader or Acrobat’s more complex process) that reflows the content. From it’s behaviour I don’t think Acrobat is simply scrapping the content, some of the formatting is retained. I’ve not dug into how/why that happens, the answer is generally to use a different PDF generator, so that’s what I’ve done previously. |
|
so what is 1.4.10 testing in the context of PDFs? that the content order is correct? if "something" ends up munging words together when a tool tries to forcibly reflow things/present the content in a different format? this all feels still very much like this isn't testing actual reflow, but structure of the underlying PDF which Acrobat uses to try and apply some proprietary reflowing algorithm, and that VIPreader uses when it scrapes the content of the PDF to show it in some completely custom way |
|
Is there any news on this? My specific question is: should a PDF document that was not generated in a way that includes reflow-capability automatically fail the SC 1.4.10, declaring the website which contains this PDF document as inaccessible (even if everything else is perfectly accessible)? Or would we add an exception for PDF documents in this SC, similarly to SC 1.4.12?
Source: https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html |
|
This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
@agwg
(It is clear that the reflow in Adobe Reader is not required für conformance with 1.4.10. My question is therefore not what required is, but what sufficient is (and I don’t want to speak in favour of one or another Reader or reflow))
My Question:
Is for PDF-Files the SC 1.4.10 met in a sufficiently way when with consideration of the exceptions (examples in the second Note) the Adobe reflow is working in a proper way according to the SC (without loss of information or functionality and without requiring….)?
Thanks
Kerstin
The text was updated successfully, but these errors were encountered: