- From: Steve Green <steve.green@testpartners.co.uk>
- Date: Fri, 1 Dec 2023 16:23:40 +0000
- To: Duff Johnson <duff.johnson@pdfa.org>
- CC: Mark Magennis <Mark.Magennis@skillsoft.com>, w3c WAI List <w3c-wai-ig@w3.org>
- Message-ID: <PR3PR09MB5268578A5496E5BA84100086C781A@PR3PR09MB5268.eurprd09.prod.outlook.com>
Thanks Duff, that is indeed very helpful. To return to Mark’s original question, images are displayed in Adobe Reader’s Reflow mode as long as they have a bounding box and were not marked as decorative in the source document. Whether you want them to be displayed in Reflow mode will depend on the context. When the page is zoomed, the images never exceed the page width, so they do not cause a horizontal scrollbar. Alternate Text is not displayed in Reflow mode, so if an image is not decorative you have at least three options: 1. Display the image in Reflow mode. 2. Don’t display the image in Reflow mode. Provide the text alternative by some means such as hiding it behind the image in the normal view. It will then be visible in Reflow mode. 3. Display the image in Reflow mode and also provide the text alternative as described above. With a bit of effort it is possible to get PDFs to display very well in Adobe Reader’s Reflow mode, but there are a number of gotchas. There are workarounds for most, but we sometimes encounter paragraphs that are centred or right-justified for no apparent reason. Also, paragraphs sometimes overlay each other vertically, and my experience has been that this cannot be fixed in Acrobat – it can only be fixed in the source document. If anyone knows how either of these issues can be fixed in Acrobat, I would be very interested to hear. Once you have fixed a PDF so it reflows nicely in Adobe Reader, there is a new question. Is this sufficient to claim that the reflow success criterion is met in an accessibility supported manner? WCAG ducks this question completely. When Adobe Reader was pretty much the only PDF reader, I think it would have been perfectly reasonable to say that reflow was accessibility supported. Now there are numerous PDF readers that don’t support reflow, I am less sure. Steve From: Duff Johnson <duff.johnson@pdfa.org> Sent: Friday, December 1, 2023 3:37 PM To: Steve Green <steve.green@testpartners.co.uk> Cc: Mark Magennis <Mark.Magennis@skillsoft.com>; w3c WAI List <w3c-wai-ig@w3.org> Subject: Re: SC 1.4.10 Reflow and PDFs HI Steve, I am distinguishing between the format and implementations thereof. I start with the fact that nothing about PDF excludes reflow, and indeed, that for >20 years PDF has included features (tagged PDF) specifically intended to enable semantically-correct reflow. An example of a file format that does exclude reflow would be a image format (JPEG, PNG, whatever) representing, for example, a scanned (or output) page-image. Accordingly, I’m saying that PDF does not automatically fail the Reflow success criterion. Rather, the question is subject to what is “accessibility supported” at a given point in time. On the above basis it may be claimed that since content in PDF can be reflowed the format, in itself, therefore “automatically” passes the criterion… but I fully acknowledge that this claim is subject to accessibility support. Sidenote: this issue reflects a more general problem with applying extant WCAG criteria to technologies beyond those for which they were designed (HTML/CSS/JS)… but that’s a digression from your question. Hopefully that’s useful..? Duff Johnson PDF Association pdfa.org On Dec 1, 2023, at 10:16, Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>> wrote: Duff, are you saying that PDFs automatically pass the Reflow success criterion on the basis that PDF viewers could reflow the content, even if they currently don’t? Steve Green Managing Director Test Partners Ltd From: Mark Magennis <Mark.Magennis@skillsoft.com<mailto:Mark.Magennis@skillsoft.com>> Sent: Friday, December 1, 2023 2:51 PM To: w3c WAI List <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>> Subject: Re: [EXTERNAL] Re: SC 1.4.10 Reflow and PDFs Thanks for that reply Duff. Very useful information and clearly presented. ________________________________ From: Duff Johnson <duff.johnson@pdfa.org<mailto:duff.johnson@pdfa.org>> Sent: Friday 1 December 2023 14:24 To: Mark Magennis <Mark.Magennis@skillsoft.com<mailto:Mark.Magennis@skillsoft.com>> Cc: w3c WAI List <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>> Subject: [EXTERNAL] Re: SC 1.4.10 Reflow and PDFs You don't often get email from duff.johnson@pdfa.org<mailto:duff.johnson@pdfa.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> A PDF doesn’t reflow in a web browser That’s a choice made by browser implementers, not a fact about PDF. The difference between what the PDF provides and the capabilities of viewing software is important to bear in mind. After all, once upon a time browsers didn’t support PDF at all; today all browsers include some degree of native support for PDF. So the real question is: when will browsers get around to more advanced support for PDF? (I’m making this point to provide background to your question, not making any claim regarding current PDF software in the 1.4.10 context. I’m not making an “accessibility supported” claim here…) But PDF reader applications like Adobe Reader have reflow functions that reflow the text both when you zoom and when you narrow the window. However, the Reflow function in Adobe Reader removes all the images in PDFs I've tested. Which means there is loss of information, which fails 1.4.10 reflow. This is NOT an endorsement… but worth noting that Adobe produces software which reflows in several ways… and, as with browsers, these are simply implementation choices, not facts about PDF. And so... - Adobe “original” reflow feature does just as you say; no support for images in reflow - Adobe's “liquid mode” reflow feature does include images (albeit at this time it does not respect the PDF’s tags :-( It should be noted that a specification for reuse of tagged PDF as HTML was published by the PDF Association some time ago, and is presently under review for an update: https://pdfa.org/resource/deriving-html-from-pdf/ Software (e.g. browsers, to use your example) implementing this specification would, of course, be able to support any sort of reflow needs, images, text-spacing… whatever. Accordingly I encourage those interested in the subject to address this problem by encouraging browser (and other) developers to take better advantage of the PDF format’s existing capabilities. So it seems like there may not be a way for users to reflow PDFs at all without losing info. Is that right, or is it maybe to do with how the images in the PDFs I've looked at are encoded? There are ways; the issue is implementation. The manner in which images in PDF are encoded is generally not the limiting factor. Of course, it’s also possible to create PDF files in which, for example, individual images are not discrete objects on the page but are instead located on a larger background canvass… this sort of PDF would not be reflowable per-se, and thus would result in a “hard fail” of 1.4.10 irrespective of software. As always, it’s possible to create inaccessible content; PDF (for format) can’t prevent an author from doing so any more than can HTML. Is it possible to include images in a way that they don’t disappear when you use Adobe Reflow? It’s not about how the images are included in the PDF; it’s about the capabilities of the PDF viewer. Or are there other PDF reading tools that reflow text without removing images? As mentioned above, Adobe’s Liquid Mode (on their mobile reader) is one such. Other apps that support more advanced reflow of PDF are produced by Foxit, WPS, Moon. The more users ask software developers for this functionality the more it will become available. Duff Johnson PDF Association pdfa.org<http://pdfa.org/>
Received on Friday, 1 December 2023 16:23:51 UTC