PDF Maker: New Bug puts <Figure> tags in the wrong reading order
Affects Windows Office users who use Adobe Acrobat PDF Maker (the Acrobat ribbon) to export PDFs from MS Office apps. Definitely affects US English versions, and may affect other language versions.
With the recent Acrobat update on either Sept. 12 or Oct. 17, 2023 (Acrobat ver. 23.006.xxxxx with PDF Maker 23 and Library 23.6.136), figures anchored in the Word.docx file do not end up in the correct location in the PDF's tag tree.
<Figure> tags are scattered randomly throughout the PDF's Tag Tree, sometimes several pages AFTER their anchor point in the Word.docx. Some <Figure> tags do get placed correctly in the Tag Tree, but the majority don't. (See the 3rd photo in the attached test PDF.)
This is a very OLD bug that has just resurfaced to haunt us again. It was common in all PDFs exported from Word up until about 2015 or so. I don't have a clue why this *&^%$#@! bug is back in PDF Maker.
— Do not update Acrobat until Adobe releases a bug fix. And turn off AutoUpdate in your account management.
— If your Acrobat was updated to version 23.006.xxxxx and now has the bug, then bypass Adobe PDF Maker entirely and use Microsoft's built-in PDF export utility to create accessible PDFs: File / Save As / PDF and check the option to tag the PDF file. This method places the <Figure> tags in the correct location in the Tag Tree. We have a free tutorial about this method at https://www.pubcom.com/blog/tutorials/ms-office/export-pdf/index.shtml
Note: Sandbox test of Word 365.docx + Exported PDF are attached.
This bug needs a critical hotfix as soon as possible. It's a lot of labor to locate where the <Figure> was placed in the tag tree and then move it manually into the correct location. On long documents with hundreds of graphics, it takes nearly a day to correct this by hand.
Denise Lehe commented
It surprises me that we are still discussing this issue in 2023. Accessibility for people with disabilities should be part of Adobe's (and all organizations') Product Design and Software Development Life Cycle.
Scott S commented
Adobe needs to increase the robustness of its QA for updates. Issues like this make it harder to make a budgetary case for Acrobat DC or Pro being essential to accessibility when that's followed up by recommendations to stop using the software.
Bevi Chagnon | PubCom.com commented
@Lynore Avery, I agree, sort of. I just didn't find any "one step forward" improvements at all, just the revert to an old bug.
Lynore Avery commented
This update seems like one step forward, two steps back.
Assistive Technology Cath commented
Abode don't make PDF obsolete - our state laws already only allow us to use accessible PDF. If you make it impossible to create accessible PDF, it will fast become a world where we cannot share PDF without fines, so please fix this issue and make accessibility a very high priority
Alana Randol commented
Severe impacts to Section 508/WCAG work in PDF documents.
Bevi Chagnon | PubCom.com commented
Agree with LS's comment about lack of concern for people worldwide with disabilities.
What makes this more appalling is that Adobe heads up the ISO committee that writes the PDF/UA accessibility standards. So they should know better and should be leading the industry.
This is critical to fix this problem. Why is Adobe not caring about human rights? I just don't get it. They may read this and say this isn't human rights, yes it is. PDFs are used by businesses, organizations, health care, governments around the world, and yet again Adobe shows that people with disabilities don't matter. Do better!!! You did better in 2009 than today. Why are we still 'voting' for accessibility for people with disabilities?????