PDFs and Reflow

[EmptyEnd6893]

I was wondering if I could clarify the requirements for PDFs and Reflow. Acrobat can reflow some documents, but forms with fillable fields cannot. I am not aware of any other PDF software that supports reflow at all, and I have seen it argued that reflowing layout runs contrary to the point of a PDF (example). Does this mean that it is not possible for PDF with fillable fields to conform to WCAG, or can an exception apply? Perhaps, as an electronic representation of paper, you could say that two-dimensional layout is required for usage or meaning. Or perhaps there is some other accessibility-supported method for making fillable PDFs reflow.

[TestPartners]

There are two separate aspects to this. The first is conformance with the success criterion. The Understanding page for SC 1.4.10 states "In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content can be reflowed...". So, in principle, if your PDF is PDF/UA conformant, it automatically meets the success criterion.

However, the second aspect is accessibility support. Adobe Reader is now the only PDF reader that supports reflow, as far as I am aware, but it does not fully support the PDF 1.7 specification, so PDF/UA conformant documents may not reflow correctly and may not reflow at all.

VIP PDF Reader used to support reflow much better than Adobe Reader, but it has not been available for more than a year. I have no idea why it was discontinued.

Since user agent support for reflow is so poor, my view is that we should not claim that a PDF is conformant just because it is PDF/UA conformant. I do think it's acceptable to claim conformance with the SC based on testing with Adobe Reader, because the WCAG definition for accessibility support explicitly avoids specifying how many user agents need to support a technology and to what extent. I would argue that Adobe Reader is sufficiently ubiquitous, but others may disagree.

Form controls and other interactive components cannot be made to reflow in PDFs, and one instance of such a component will prevent the entire page from reflowing, although pages without such components will still reflow in the same document. Since the use of forms in PDFs is not accessibility supported in terms of reflow, almost all PDF forms cannot be made WCAG conformant. That said, if the form and everything else on the page fits within the equivalent of 320 CSS pixels (which will be pretty rare), the SC will pass because the contents will not need to reflow.

However, it gets more complicated with other content types. For instance, if you include an image with Alternate Text in Microsoft Word, that page will not reflow in the resulting PDF. However, if you include an image with Alternate Text in some other applications (InDesign being one, I believe), the page will reflow in the resulting PDF. The difference is caused by some parameter buried deep in the tag properties, and you can actually fix it for PDFs created using Word if you know what to look for (and I forget what it is).

I would ignore the assertion that "the core of PDF is to place text at a fixed point in space". This may or may not have been true 30 years ago, but it's absolutely not the case now. It's only one of many use cases for PDFs.

[lrosenthol]

However, the second aspect is accessibility support. Adobe Reader is now the only PDF reader that supports reflow, as far as I am aware, but it does not fully support the PDF 1.7 specification, so PDF/UA conformant documents may not reflow correctly and may not reflow at all.

The PDF 1.7 specification was produced by Adobe and was written to match the implementation of Adobe Acrobat. That document was then transitioned to ISO and published by them as ISO 32000-1.

So I would have to ask what specific part(s) of the PDF 1.7 specification you believe are not supported by Adobe Acrobat. If you cannot cite the specifics, I would ask that you retract the statement.

Since user agent support for reflow is so poor, my view is that we should not claim that a PDF is conformant just because it is PDF/UA conformant. I do think it's acceptable to claim conformance with the SC based on testing with Adobe Reader, because the WCAG definition for accessibility support explicitly avoids specifying how many user agents need to support a technology and to what extent. I would argue that Adobe Reader is sufficiently ubiquitous, but others may disagree.

You seem to be mixing two separate set of requirements - one being file format and one being UA.

A PDF that complies with PDF/UA is 100% WCAG compliant. Those are both specifically file format requirements.

For UA requirements for WCAG, there is a separate document called the "User Agent Accessibility Guide" at https://www.w3.org/WAI/standards-guidelines/uaag/. In PDF/UA-1, you will find their specific UA (called a "Conforming Processor") requirements directly in the text.

Form controls and other interactive components cannot be made to reflow in PDFs

That is not technically true provided that the PDF is properly tagged, for example accordingly to the recently published Well-Tagged PDF (WTPDF) specification at https://pdfa.org/wtpdf/. WTPDF is also the basis for PDF/UA-2. The PDF Association is actively working to update their "Deriving HTML from PDF" specification (https://pdfa.org/resource/deriving-html-from-pdf/) to include form fields, annotations and other interactive elements.

However, it gets more complicated with other content types. For instance, if you include an image with Alternate Text in Microsoft Word, that page will not reflow in the resulting PDF.

I am not aware of any basis in fact for this statement. AltText for images is a core feature of PDF/UA, WTPDF and specifically supported by various UA's offering reflow including Adobe Acrobat.

[DuffJohnson]

However, the second aspect is accessibility support. Adobe Reader is now the only PDF reader that supports reflow, as far as I am aware, but it does not fully support the PDF 1.7 specification, so PDF/UA conformant documents may not reflow correctly and may not reflow at all.

As of May 2025 neither the reflow or Liquid Mode features in Adobe Reader leverages tags in the PDF. Accordingly, any reflow they perform is implementation-dependent.

At this time the only mainstream PDF viewer I’m aware of that reflows PDF based on the tags already present in a PDF is Foxit Reader, and it’s not perfect.

These things change rapidly; software could provide / improve this support at any time.

[mraccess77]

In my opinion if the PDF meets PDF/UA and the images are properly configured to allow for the reflow of the text without requiring two-dimensional scrolling per the criterion - I don't think a PDF should fail just because no current agents don't support the being done according to the specification.

[TestPartners]

But WCAG specifically requires that all the technologies that are relied on for conformance are accessibility supported. If a PDF cannot be reflowed in any user agent, it means you are using a technology in a manner that is not accessibility supported, so the document is not WCAG conformant.

[lrosenthol]

But WCAG specifically requires that all the technologies that are relied on for conformance are accessibility supported.

I cannot find anything in WCAG 2.2 (https://www.w3.org/TR/WCAG22/) that makes that statement. Can you clarify?

[mraccess77]

5.2.4 Only Accessibility-Supported Ways of Using Technologies
Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)

[lrosenthol]

@mraccess77 What that quoted section says is NOT what was said by @TestPartners .

What 5.2.4 says is that "accessibility compliance is evaluated 'end to end'". That means that for a given SOLUTION (not a given TECHNOLOGY) you evaluate not only the content but the system/app/etc. that is consuming the content and presenting it to users. It also means that a compliant "accessible technology device" (e.g., screen reader) is also required in some cases. I agree 100% with that.

So back to the original statements in this thread - PDF is a file format which (like HTML) can be made accessible or not. There exists many PDF readers (as there are HTML UAs). If you want to determine if a given document is accessible, you must do so considering the reader (UA) in which it is viewed and in conjunction with any required AT devices.

Just as a given HTML page can be inaccessible (or specifically not compliant with WCAG) if viewed in a non-accessible UA (or on a system without a screen reader present) - the same is true for PDF. If you take a PDF/UA (and therefore WAG) compliant PDF and view it in a reader that is not accessible and/or on a system without that screen reader - IN THAT CASE - it isn't WCAG compliant. BUT if I view it in a properly accessible reader with the necessary AT device - then it complies.

Agreed?