I too have come here regarding accessibility issues. I have submitted a bug regarding OCR of text, and that images are not OCR'ing. This is critical for accessibility and search features in PDF files. Although Adobe may claim it is because the image has a background, the Mac OS Preview application which is free and comes on every computer OCR's all text in these images with no problem.

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.

https://support.microsoft.com/en-us/office/improve-accessibility-with-the-accessibility-checker-a16f6de0-2f39-4a2b-8bd8-5ad801426c7f#PickTab=Windows

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?

Thanks for getting this update completed. I have uploaded the latest version and will check it out further.

Thanks, great to see!

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

@AnandSri

and the Adobe Acrobat development team

and the Adobe Accessibility Team,

Thank you!

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.

Thank you!

— 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.

See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017

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.
Tani Hubbard

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!

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.

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?

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.

Cheers!

Mike

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.