A PDF's "Logical Structure" is stored separately from the PDF's content.
"Tagged PDF" is a stylized us of PDF that builds on "Logical Structure".
So, the "Logical Structure" and the structure tree of a "Tagged PDF" is independent of the PDF's page content.
(Details in ISO 32000)
If you replace PDF1 pages with PDF2 pages you have not/do not affect PDF1's structure tree. It is still present and its "build" presumes the replaced page content is still present.
As well, you bring in PDF2's structure tree.
For form fields or comment/markup annotations on a PDF1 the replace pages can be useful it can make a mess of tagged PDFs.
When a Tagged PDF is used via replace page(s), insert page(s) and such this PDF's structure tree will be appended to the end of the existing structure tree.
When manually assembling many PDFs into one you'd open the first (say Chapter_1.pdf) then insert the next in sequence behind the last page of this "first in content" PDF.
Continue down the line.
Yes, this occurs. It is expected behavior when adding/inserting tagged content from one PDF to another.
While PDF page content may be insert before of after other PDF page content with the content sequence reflected appropriately, tagged content for inserted page content is always appended to the end of the structure tree.
Conversely, deletion of PDF page content does not delete the associated tagged content from the "host" PDF.
This is because the structure tree content is separate from PDF page content.
I appreciate your explanation about what is happening and why it is happening. However, I'm still at a loss as far as an efficient way to deal with replacing pags in an accessible PDF form.
1 person found this helpful
"However, I'm still at a loss as far as an efficient way to deal with replacing pages in an accessible PDF form."
Well.... ya see, there is no "efficient way".
You can do the replace task then its sleeves up and into the structure tree.
Time intensive (very).
The key success precursor is a solid grasp of ISO 32000 (in particular section 14) - but that can be a tough chew.
It'll help having ISO 14289-1 (PDF/UA) once it is on the street - but that's down the time line some.
The "helper" docs that Adobe put out in days bygone facilitate working up accessible PDF. Unfortunately they are no longer readily available.
I am wondering and hoping that maybe something has changed on this front of tagged pdfs in the last six years?
Also, can anyone tell me what advantage there is to tagging form fields when the screen reader still reads the tooltips? We have many, many forms that get updated by replacing the image behind the fields, it's just not feasible to tag the 200 plus fields every time they are updated.