Accessible PDF loses reading order on form fields after flatten form

While trying to make our pdf documents accessible we encountered the folling problem.

Our PDF documents contain data per customer and are generated per customer. We use pdf templates with text, images and form fields. The form fields get filled with xfdf data server-side and are flattened thereafter. Additionally a watermark is added.

We use Adobe Acrobat XI Pro to create the pdf templates. Converting the pdf templates to make them accessible was no problem.

The problem occurs once we flatten the forms on the server. All form fields get removed from the reading order and JAWS will not read them anymore, because the tags are invalid.

The same problem can be seen by just flattening a form with Adobe Acrobat (save as optimised pdf with flatten forms only).

If you had a reading order that goes like this:
text > form field > text
it changes to:
text > text

Is there any way we can preserve the reading order that we defined in the pdf template once we flatten the pdf form after it gets filled with xfdf data?

Tools we are using:
- Adobe Acrobat XI Pro
- PDFTK
- JAWS 16


Erik Raetz


5 Answers

Voted Best Answer

We sat down and tested our last approach with the protected/encrypted pdf document a bit more because the preserved reading order looked so promising. First we tried the default screen reader of the Adobe Reader. After enabling "read form fields" under preferences the default screen reader read the full document in correct order while announcing the correct values. Nice.

That got us thinking and we digged a bit more into JAWS shortcuts. Here is the thing. We were navigating in the document with cursor-keys all the time. But for whatever reason that produces a different outcome as if you would have read JAWS the document. Then it behaves like the default reader and reads everything like it should.

JAWS shortcuts for Adobe Reader
http://www.adobe.com/content/dam/Adob...

From our standpoint the problem is solved. If anyone has something else to add feel free to do so.


By Erik Raetz   

The culprit is the flattening process.

With flattening, any form field information gets lost, while the field value becomes part of the base PDF, and it does not have any structure information, making it very difficult for the screen reader to find the data from the flattened field (it is probably at the very end of the page).

One possibility would be to recreate the PDF instead of flattening it. (well, is there a need to flatten; would making the fields read-only be sufficient?)

Hope this can help.

Max Wyss.


Max Wyss   

Thank you Mr. Wyss.

The screen reader reads the full pdf if no tags are defined (in a reading order the user defines in the reader that does not match the reading order we need).
If any tags are set the screen reader will only read tagged fields and ignore the rest.

Making all form fields read only would still make the fields visible right?
Is that a JavaScript solution that is triggered in the reader upon opening the the document?

Currently the only information on that topic I could find is a short changelog note on iText where they talk about how to preserve the StructTreeRoot. http://itextpdf.com/release/itext544


Erik Raetz   

We just checked your read only suggestion and that made us dig into PDFTK permissions.
https://www.pdflabs.com/docs/pdftk-ma...

Our PDF is now set to printing and screen readers only instead of flatten. This preserves the reading order.

That may actually be the solution we are looking for. Thanks a ton.



Erik Raetz   

We just tested the protected PDF version in JAWS. He does not read the field data.

The PDF looks like this in Acrobat:

http://imgur.com/X3ykfsF

Reading order is correct and preserved. Additionally I cannot see any changes regarding content or tag structure. Only thing that changes is the data of the form field (which is xfdf driven).

The form field is displayed as an annotation. I can add an alternative text to the annotation and he will read it but he will not read the text inside the annotation.


Erik Raetz   


Please specify a reason: