Accessibility Errors with PDF Maker Update Sept 2021
Several major bugs have been documented by users in the Adobe Community Forums since Acrobat and PDF Maker were updated on September 14, 2021.
1: Alt-Text from MS Word is not converting into the PDF. Instead, it is dropped and gibberish code is inserted. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017 This violates the PDF/UA-1 standard which requires that every graphic have alt-text that verbally describes the graphic.
THIS IS A HUGE BUG. You essentially have made Acrobat unusable for those who are required by their country's laws to make fully accessible PDFs.
2: Every cell border on every table cell is being tagged as:
<P>PathPathPathPath. This violates PDF/UA-1 because unnecessary visual formatting is not being tagged at Artifacts.
3: The underline on Hyperlinks should be tagged as artifacts. Right not, it appears as one or more "PathPathPath" which is announced by different assistive technologies. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017
4: Borders and background shadings on Text Boxes are being tagged as a combination of <Figure>s and PathPathPath. This too is a violation of PDF/UA-1. https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017
5: Paragraph borders and shadings: same deal as #4 above.Per the PDF/UA-1 standard, they are visually decorative and should be artifacted. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017
NOTE: To be correctly tagged per PDF/UA-1, the borders/shading content should:
— Not appear anywhere in the Tag tree, either as <Figure> or as "Path" in a yellow content container box.
— Not appear in the Order panel.
— Should appear as Artifact in the Content panel.
6: Dragging and dropping elements in both the Tag and Order panels is now broken.
The text cursor doesn't show anymore, and the little black line doesn't show anymore and instead appears several inches away from where it really is. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017 and also https://community.adobe.com/t5/acrobat-discussions/acrobat-pro-reading-order-box-and-tag-dragging-no-longer-visible/m-p/12395226#M329877
7: Once this update is installed, users can't revert back to a previous version of PDF Maker because Adobe doesn't allow that in Acrobat like it does with other Creative Suite applications.
So once the update is completed, it makes PDF Maker completely unusable for tagged accessible PDFs.
This affects millions of your government customers world wide, as well as millions of government contractors and millions of academic customers...all of whom are required by their country's laws to make accessible PDFs.
2 sets of sample Word and Matching PDF files are submitted as demonstrations of the problems in the exported PDFs via PDF Maker.
Thank you for raising these accessibility issues. The post mentions about the following six bugs being introduced with the update that went live on September 14, 2021
1: Alt-Text from MS Word is not converting into the PDF. Instead, it is dropped and gibberish code is inserted
2: Every cell border on every table cell is being tagged as <P>PathPathPathPath
3: The underline on Hyperlinks should be tagged as artifacts
4: Borders and background shadings on Text Boxes are being tagged as a combination of <Figure>s and PathPathPath
5: Paragraph borders and shadings: same deal as #4 above.Per the PDF/UA-1 standard, they are visually decorative and should be artifacted
6: Dragging and dropping elements in both the Tag and Order panels is now broken.
Would like to mention that out of these, #1 and #6 were introduced with the Sep 14 update and remaining (#2, #3, #4 & #5) were present even in the Acrobat version prior to Sep 14 update. We apologize for the inconvenience caused by these issues.
Issue #1 and #6 were the regressions introduced with Sept 14th update and hence were fixed on priority with Sept 29th Update (Release Notes for September 29, 2021). With the latest version (22.001.20085) of Acrobat Pro DC released on March 7th (Release Notes for March 07, 2022), issues #2 and #3 have also been fixed. Issues #4 and #5 have been partially fixed so that PathPathPath tags won’t be part of the tag tree anymore. The remaining issue for #4 and # 5 (Borders and background shadings on Text Boxes / paragraphs are being tagged as <Figure>s) have already been added to our product backlog and those will be prioritized to be fixed in coming releases.
You can use the menu item Help → Check for Updates… to get the latest version of Acrobat Pro DC containing these fixes. Please try out the fixes and share the feedback as that will help us make our applications better from accessibility perspective.
Thanks & Regards
I have found a solution to this issue and I wanted to document it here in order to help anyone else who runs across this issue in the future.
I opened the problematic file in Word, went to the Review tab on the ribbon, and clicked the Accessibility Checker button. The Accessibility Checker identified 29 instances of the "No header row" error. Next to each Table under “No header row” I clicked the Recommended Action “Use first row as header.” After doing this for all 29 instances it identified, when I created the PDF all of the tables passed the Headers check. I have no idea what was different about those 29 tables compared to the other tables in the report, but this appears to be a good way to fix the TH/TD issue in the Word document rather than having to fix it in the PDF. It seems faster to me than the typing required to correct it in Adobe Acrobat.
@Tanvi Rastogi Thanks for your response. I figured out what was causing the problem and the difference between the two documents. The Word document that was causing problems had tracked changes turned on and tracking was locked using a password. When I unlocked tracked changes using the password and turned off tracked changes before creating the PDF, the PathPathPathPath tags were no longer present. While I'm not sure why tracked changes would matter, I am now able to avoid having to manually delete each PathPathPathPath tag in the PDF file so I am happy! Thank you.
Here is an example file to show the issue I am experiencing. In File A.docx, you can verify that all four tables (Tables 1-4) have the first row marked "Repeat as header row at the top of each page". However, in File A.pdf, you can see that the accessibility check flags "Tables > Headers - Failed" for Tables 1 and 2, but the accessibility check passes this check for Tables 3 and 4. Why do they appear to be formatted similarly yet produce different outcomes?
In order to meet contract requirements at work, I need to convert Word documents into section 508-compliant PDFs on a regular basis. On some of my PDFs, when I run the accessibility check, I am having issues with Tables > Headers - Failed. In my example document, there are 56 tables. Of these tables, 29 are flagged as Tables > Headers - Failed. I can correct this in Adobe Acrobat by doing the following: showing the Tags Panel, opening the first <TR> tag of each problematic table, and changing each tag under that from <TD> to <TH>. However, this is tedious and I would like to make the corrections in Word rather than in Acrobat. Also, I have to regenerate the PDF multiple times as we work with the document so I would prefer to avoid the rework of having to change the <TD>s to <TH>s every time.
Everything I have read tells me I need to go into the Word document, right-click on the table, select Table Properties, click the Row tab, and select "Repeat as header row at the top of each page". Theoretically, after I do that for all of the problematic tables, I won't have this Tables > Headers - Failed issue and all tags for the top row of cells in the table will be <TH>. However, after I completed this for each problematic table in the Word document, the PDF I create is exactly the same and still contains the same 29 problematic tables. Is there something else that needs to be corrected in the Word document to make the Tables > Headers accessibility check pass in Adobe Acrobat?
If this is helpful, the versions I am running are:
Word: Version 2202 (Build 14931.20132)
Adobe Acrobat Pro DC: Version 2022.001.20085
I recently updated to version 2022.001.20085 in the sincere hope that issue #2 from Bevi Chagnon's original post (Every cell border on every table cell is being tagged as: <P>PathPathPathPath) would go away for me. I was initially excited to see that the PathPathPathPath tags were not added to the first document that I tried. (0/24 tables in the document contained the PathPathPathPath tags.) Excellent! Then I created a PDF of a different document following the exact same process, and unfortunately all 56/56 tables in the document contained the PathPathPathPath tags. Is there any reason why two different documents would do the exact opposite with regards to this particular issue in version 2022.001.20085? Do I need to modify something about the Word document?
Sue Pare commented
Thanks for getting this update completed. I have uploaded the latest version and will check it out further.
Thanks, great to see!
Rachel ST commented
Great news! Thanks!
Before and after sample test files. Compare the tag trees in both samples.
Before the update = Acrobat PDF Maker 21
After the update = Acrobat PDF Maker 22
@Tanvi Rastogi and
and the Adobe Acrobat development team
and the Adobe Accessibility Team,
This update improves the lives of 1/3 of the world's population that must use assistive technology to read and use PDFs.
That's 2.5 billion people.
Oh ... plus all of the millions of workers, authors, and educators worldwide who are required to make accessible documents per their country's human rights laws that require all content to be accessible to everyone.
You've done a good thing for society.
— Bevi Chagnon
PS: only one item above still needs work: the Word text box converts to a <Figure> tag, which should be artifacted. The rules and text are now tagged correctly.
I'm hoping we can see this correction soon!
Adobe do better! For the love of god, it is 2022, and here we are...why? Why is accessibility not put into your every day workflow, with checks at every single step from the absolute beginning? I am so frustrated with you. I have used PDFs since the beginning, the absolute beginning and we had an easier time making PDFs accessible in 2010 then today, why is this so problematic? Microsoft changed their culture about 7-8 years ago, and while they aren't perfect, I no longer have to tell clients how bad their product is...now I say that about you! What will it take? Do we need to do a class action lawsuit in every country? Why do we need to beg for basic accessibility fixes????
Repeating issue #2 from above:
2: Every cell border on every table cell is being tagged as: <P>PathPathPathPath. This violates PDF/UA-1 because unnecessary visual formatting is not being tagged with the artifact attribute.
The problem is with Adobe's conversion of Word to tagged PDF: the utility is creating an <Artifact> tag, which doesn't exist in the PDF/UA-1 standard where artifact is an attribute on a tag, not a tag/structural element.
Because the <Artifact> tag doesn't exist (it might be in the future PDF/UA-2 standard), Adobe role mapped it to a <P> which now causes PathPathPathPathPath to be discovered by assistive technologies and voiced by screen readers.
Every side of a border. On every cell. In every row of a table.
What a mess.
NOTE: The PDF/UA-2 standard is in development and not available to the public or most AT manufacturers. So the future <Artifact> tag is not recognized or processed by any AT on the market today. It will be years before this new standard becomes widely adopted and available for use.
Until then, Adobe needs to revert PDF Maker back to its previous setting where it placed the artifact "attribute" on PathPathPath, instead of using a vaporware <Artifact> tag.
This is a HUGE violation of accessibility / ADA laws worldwide.
See sample Word and PDF from the latest version (February 2022).
The BIGGER question is: why is Adobe building PDFs to a standard that doesn't yet exist? It's failing the people who depend on their technology.
Please fix the <p> PathPathPathPathPath that shows up in every single <TR> tag in PDFs. It is making it extremely difficult to make documents (especially long ones) 508 compliant. They all have to be deleted by hand, which can take hours. While using Save As PDF fixes that problem, it introduces other 508 compliance issues, so there's more work either way.
Guy Ivie commented
Item #2 is a big problem with our table-heavy documents, and it cropped up only in the past couple of months. It takes an inordinate amount of time to visit each table tag and artifact out the <P> PathPathPathPathPath at the beginning of the header so that the tables will pass the checker.
Can't understand why Adobe can't get it right in the first place, and then leaves customers around the world hanging in the breeze. Fix the problem!
Rachel Ford commented
These items are also an issue if exporting a document from InDesign to Acrobat. Marking text as artifacts, or images as PathPathPathPathPathPath is not ok. Please fix these issues quickly, because we need to be able to post accessible PDFs.
Julie Harris commented
I have Adobe Acrobat DC (21.011.20039) installed and am still having trouble with Bug #1, described above: Alt-Text for images from MS Word is not converting into the PDF. Instead, it is dropped and gibberish code is inserted. Is the Acrobat plugin for Word still not working?
Mike Craghead commented
Re: Bug #2: "<P>PathPathPath..."
Here is a super dumb way past this bug:
In Word, do NOT use File >Save As PDF. Instead,
Go to File > Save As > [choose PDF from the file type droplist] > press Save.
No more PathPathPath!
It's objectively silly that File > Save As PDF should give you different results than choosing the file type manually. It doesn't create an accessibility nightmare like printing to PDF does, but those PathPathPath errors can really add up!
Anyway, I was happy to find this fix, hope you all have similar success with it. But Adobe: do please fix this. Microsoft could help by tweaking their GUI to steer users more intuitively to the right path, but we mustn't count on that!
Couldn't a function be added to Acrobat that seeks out every "<P> PathPathPath..." and kills it with fire? There is no circumstance in which that tag with those contents would be useful. And isn't it all just plain text XML if you're deep enough under the hood, addressable with a little basic find-and-replace logic? I don't know much so I'm just speculating, but it sure looks plausible through my ignorance-colored glasses.
Vikki Howe commented
I work on GOV.UK for the Department for Education and this bug has had a huge impact on our content's accessibility.
This can currently only be fixed by manually clicking into each cell row and deleting the P tag (unless there are any other work arounds?) Some of our research publications have over 40 tables in them and this is having a huge impact on our teams’ resource. We are having to spend hours, days fixing PDFs to ensure this error is fixed and the content meets the new accessibility legislation that came into force for public sector content back in 2018. This is having a direct impact on our publishing deadlines.
This also has an impact on all PDFs with tables previously published on GOV.UK. When we initially published content it was accessible but with this update these publications no longer are. This is a global issue and will affect the accessibility of 1000s of publications on GOV.UK.
Please can you let us know when we can expect a fix for this.
Hi Tanvi, can I just check if you have a fix date for this issue? Thanks.
Thanks for the updates.
Bugs #2-#5 are indeed from a previous release, but they are now being flagged as errors in Acrobat's internal accessibility checker, especially in Table Headers.
Note: PathPathPath is a serious accessibility error no matter where it appears, not just in table headers.
Please don't wait until spring to fix this with all of the PathPathPath, whether they:
— appear in an <Artifact> tag (which is not a legal PDF/UA-1 tag),
— are role-mapped to <P> (which makes them discoverable by assistive technologies),
— are embedded and mixed in with the content,
And please don't tell us to turn off checking table headers (we're required by various country laws to ensure they are accessible). That's not allowable because we'd be breaking our laws.