Table headers fail in Accessibility Checker after September 14, 2021 update

[Eileen M5E53]

On September 14, I made accessible a large document with 61 tables.  After properly scoping/tagging tables, I ran the Accessibility Checker and the document passed with no table fails.  On September 15, I reran the Accessibility Checker and there are now 61 fails for table headers even though the tables are tagged properly.  I had someone I work with run the checker on the same document using Adobe Acrobat 2017 and the tables pass with no errors.  What changed with the 9.14.21 update??????

[josephineg93776361]

Our shop is having this same issue. Regarding the software "patch" above, what about when people run the checker who have not manually inserted this patch?  The document will pass our checker, but not theirs.  The other recourse provided is to correctly label table header cells.  But our tables are failing with table cells correctly labled "TH". 

Please enlist the help of Adobe's top programmers.  The September release is very flawed for accessibility work. 

[Bevi Chagnon - PubCom.com]

@josephineg93776361 

Here's a solution that works at our remediation shop:

1. Open Acrobat DC Pro's Preflight tool panel. (Standards tool panel / Preflight)
    
2. Select the PDF/UA section and click to expand it.
    
3. Select the little grey wrench for Fix problems in PDF tagging structure.
    
4. Then select the magnifying glass button Analyze and Fix in the lower right of the dialogue box.

This should fix the problem that Adobe has built into the PDF, which is:

The borders around each cell of each row are being tagged with the <Artifact> tag. This is a huge overstepping of the standards by Adobe because THERE IS NO <ARTIFACT> tag in PDF/UA-1, the current published official standard. There may be one in the next standard, PDF/UA-2, but that is a vaporStandard in its umpteenth rewrite at this time and, if all goes well  should be published in a couple of years, and then it will be a couple more years after that for assistive technologies and checkers to recognize and process it correctly.

So because the <Artifact> is not a legal tag at this time, Adobe is role-mapping the <Artifact> tag to a <P>, which now makes all that junk discoverable by ATs, including screen readers that voice it as PathPathPathPathPath...one path for each segment of the border.

Combined, it creates one messy, complex error that is correctly flagged in any PDF Accessibility Checker: The whole table structure is now incorrect because there's a <P> tag lose in the <Table> tag. That's a violation of the PDF/UA syntax.

Adobe's tables look like this:

<Table>

     <P>PathPathPathPathPathPathPathPathPathPathPathPath (this is the error: shouldn't be in the tag tree)

     <TR>

         <TH> etc.

Should look like this:

<Table>

     <TR>

         <TH> etc.

—Bevi

US Delegate to the ISO committees for PDF and PDF/UA.

[Bevi Chagnon - PubCom.com]

Also, this series of bugs is documented at UserVoice, https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/44183082-accessi...

Please visit the page and VOTE to get it fixed.

(I know I know, it's so crazy that we have to vote to beg Adobe to fix the bugs.)

[josephineg93776361]

Thanks so much for providing this information, @Bevi Chagnon - PubCom.com, and for championing this fix.  My vote is in! 

I followed your instructions, including a few extra steps since I did not have Preflight on my tool bar. But I did not have any success with the process.  Here's what I did:

1. Add the PDF Standards tool to tool side bar in Adobe (Tools > Protect and Standardize > PDF Standards)
2. Click on PDF Standards tool icon in tool side bar

3. Click on the sub-tool, Preflight
4. Click on Standards button at top center of Preflight window and choose PDF Standards
5. In the list, next to PDF/UA click the drop-down and click on grey wrench next to Fix problems in PDF tagging structure

6. Click on Analyze and fix button (lower right of dialogue box)

I received this output:

I was a little sorry to see that it said "No porblems found" at the end, and running the checker confirmed my fears, as I still have the same table errors:

Am I doing something wrong?

By the way, your explanation about the artifact fix being years down the road is very helpful information.  All the more reason for Adobe to release an October update that (secretly) returns us to August. Thank you, Bev, for all your hard work on this!

~ Josephine

[carrieg77610942]

I am so glad I am not the only one!! This is a massive issue! Bevi - neither work around is working! I attampted to make the pathpathpathpath tag an artifact and it wont change. I also did the pre-flight solution and nothing changed there either. Do you have any other suggestions? 

[Bevi Chagnon - PubCom.com]

Yes, I'm with your @carrieg77610942  and everyone else!

We notified Adobe's accessibility team and engineers about the problem over a year ago and it's been ignored by them. The problem is caused by a deliberate mis-programming of the converter that creates the tagged, accessible PDF: it's not following the PDF/UA-1 standards.

It's disgusting what this bug does to those with disabilities and use assistive technologies.

And it's equally disgusting what it forces us document creators and remediators to have to do to fix the PathPathPathPathPathPathPathPathPathPathPathPathPathPathPathPath crud they're putting into the PDF files.

&^%$#@!

I'm going to create a small tutorial on how to fix this during the coming week. Will post here in the forum when it's ready.

But in the meantime, VOTE UP this bug!  We need many more votes to get Adobe's attention on this.

Vote at https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/44183082-accessi...  #1 and #6 were fixed by Adobe, but the remaining ones are still there.

And please let all your colleagues know about this problem and encourage them to vote, too. This is the only way we have to tell Adobe to get this corrected ASAP.

[AppleTea77]

Hi Rachit, Thanks for your reply on this. The only thing is it says, in relation to this workaround, that 'The registry key bypasses the error, and does not flag or fix the missing table header accessibility issue.' - therefore it seems to be saying that if we get error alert after the update, there is a problem there with the table headers which had not been detected before the update - but this doesnt make sense because the table headers are correctly tagged in my documents and now the error is coming up - so it seems is this more to do with a problem with the checker? rather than there being an accessiblity error in the documents which was not previously detected? (And why would we want to use this workaround if it is only just bypassing an error? If this was the case don't we want to know why the documents are not meeting the accessiblity check, rather than just ignoring it?) I wondered if any chance you could explain what is happening here as we have created multiple documents all which passed the accessibility check and now dont so would really like to understand what is going on? is the problem to do with the update rather than there being an error that was previously not detected? Thanks so much, 

Claudia

[Bevi Chagnon @ PubCom]

is the problem to do with the update rather than there being an error that was previously not detected? Thanks so much, 

By @AppleTea77

Yes.

The tables have been incorrectly tagged by Adobe for a few versions. It appears that the Acrobat checker has been updated and is now flagging the error. It's flagging the error only in the table header row(s) but the error is there in all table rows <TR>.

(3rd party checkers have flagged the error for a few versions, too, so Acrobat is catching up.)

See my earlier post on October 5, 2021 for a detailed description of what's happening and why.

Bottom line: Adobe's export utility has been mis-tagging tables and the Acrobat checker just caught up with the error and flags it.

Best workaround: Use Word's built-in converter rather than the Acrobat ribbon. It's a very good utility.

File / Save As / and then select PDF as the File Type. Set your options, and go with it.

[AppleTea77]

Many thanks for your help

[AppleTea77]

PS could you send me a link to your earlier post? I cannot seem to find it. Thanks so much

[Bevi Chagnon - PubCom.com]

@AppleTea77  that detailed post from Oct 5 2021 is at https://community.adobe.com/t5/acrobat-discussions/table-headers-fail-in-accessibility-checker-after...

It details how to correct some of the issues in Acrobat's Preflight utility, and what causes the problem (it's the way Adobe PDF Maker tags the PDF when we export from MS Word).

But the best solution we recommend is to use Microsoft's built-in PDF utility shown above.

And don't forget to Vote for the bug fix at

 at https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/44183082-accessi...  #1 and #6 were fixed by Adobe, but the remaining ones are still there.

[AppleTea77]

PPS I have created multipol PDFs with Adobe which the accessibility checker is now detecting these table header errors in. Does that mean if I want to ensure they are all accessible I have to recreate them again? Or is there another way of doing this? as the former will take a long time.

[Bevi Chagnon - PubCom.com]

As I mentioned earlier, the table tags were broken a few versions back, it's just that the Acrobat checker didn't flag them. Now, it's flagging them...well, flagging them only in the table headers and not elsewhere in the table.

Don't ever trust and rely on any software checker to completely verify that the file is compliant. No software can do that and the manufacturers have different interpretations of the standards.

Our accessibility firm takes these measures:

1. Make the most "born-accessible" source document possible. Do it right the first time.
    
2. Use the best tool (at the time) to export the most compliant PDF possible. So that isn't Adobe's PDF Maker at this time (Fall 2021). MS's is doing a better job. Periodically test all methods because these companies leap-frog over each other with each new release.
    
3. Run 2 or more accessibility software checkers, which will flag the stuff that they can evaluate, but overlook others or flag them as errors. This is a very detailed task that requires someone with training to figure out what's right, what's wrong. This person is like an excellent car mechanic who can diagnose and repair problems,
    
4. Manually correct errors. (You'll need to do that with this particular bug. See below.)
    
5. Use 3rd party tools to correct errors. (Don't know of any that can detect and correct this bug.)
    
6. Test by humans using screen readers and other assistive technologies. Use JAWS, NVDA, VoiceOver (Apple), etc. That's where you'll hear the problem with <P>PathPathPath.  Reveiw and correct any problems you find.
    
   7. Once the file is corrected, use Acrobat's built-in Preflight utility. Instructions at https://community.adobe.com/t5/acrobat-discussions/table-headers-fail-in-accessibility-checker-after... (Oct 6, 2021).

That's a lot of work! If you have the original Word source document, I'd open it in Word and re-export it using the Microsoft export described above. https://community.adobe.com/t5/acrobat-discussions/table-headers-fail-in-accessibility-checker-after... (Nov 2, 2021).

Manual correction to fix this bug in Acrobat:

• Open the Content Panel and locate each "Path" that you find.
   
• Right-click and select Artifact.
   
• Move to the Tag Panel and locate the now-empty tag that used to hold the "Path". Delete it.
  Note: Ensure that the tag is really empty, not even with a spacebar. An empty tag doesn't have a yellow container box inside it, nor an expansion arrow to its left. If you delete a tag while it still contains content, even a spacebar or return, you'll get an untagged content error in your checkers.
   
• For this nasty bug, you'll have to search through every row of every table for those "Path" fragments. You can sometimes use Control+Click to select more than one at a time while you artifact them. Sometimes not.  And sometimes you['ll find "Path" stuck in between real content, like: This is bodyPath text.  See if you can artifact them, too.

And did I mention that you should Vote UP this bug at UserVoice? And tell your colleagues to do the same. Keep the votes coming because UserVoice is the only way to let Adobe know what we need.  https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/44183082-accessi... 

[AppleTea77]

Thanks so much for your help,

C

[Bibiana232694109jam]

I tried to find the place to make the work around, but its not there. Really need to fix this issue. Our documents have dozens of tables and this is inefficient.

[Tanvi Rastogi]

Hi all

Thank you for raising these PDFMaker accessibility issues.  We are evaluating the issues for inclusion in upcoming releases. 

Thanks for your patience.

-Tanvi

[josephineg93776361]

Thank you, Tanvi and HUGE thank you to BEVI.

Tanvi, is there any way Adobe can provide a stop-gap while you work toward a solution?  If we could go back to the previous version of the accessibility software, that would be so appreciated by thousands of workers!  Please, please help us. The table issue is especially challenging.

Thank you,

Josephine

[JinitB]

Hi Tanvi

Can I check if you have any update on when this issue will be resolved in Adobe?

Seems to be a few workarounds suggested but I would like to create my accessible documents using Adobe.

Thanks

[L Wick]

I've been playing around with this, and found if I click File > Save a Copy > and change the file format dropdown to PDF, the table tags appear to be correct and aren't flagged as an issue by the Accessibility Checker:

[L Wick]

Sorry, I should have stated this was in Word for Office 365. I've spot-checked a few other files from the past two years, the files that list PDF Producer: Adobe PDF Library in Properties all have the <P> tags at the start of each table row. The files I've found that list PDF Producer: Microsoft Word for Office 365 have the tags above.

[Bevi Chagnon - PubCom.com]

@L Wick  Yes, that's correct.

PDF's exported with Adobe's Producer/Library XX (aka, PDF Maker or the Acrobat ribbon in Word) put <P>PathPathPath tags at the beginning of every table row <TR>. This bug is documented earlier in this thread.

However, PDF's exported with Microsoft's built-in Producer (File / Save As / PDF) doesn't create the <P>PathPathPathPath tag.

So using MS's PDF export utility is one workaround. See documentation earlier in this thread.

[kga-rti-kga]

I know this is an old thread, but the table tagging is still an issue.

I have Acrobat Pro Version 2024.002.20687.   When I use the Acrobat add-in from the Word ribbon, or the Save as Adobe PDF option, my PDFs usually have table errors (one being the extra <P> tag (and/or  <P>PathPathPath) tags at the beginning of the table row tag structure.

When I use the "work around" method  "Saving As" and then selecting PDF as the file type, the table produces no errors; HOWEVER, my documents have no bookmarks. Not a big deal if it is a small report, but I'm currently working on a very large report (over 400 pages; lots of appendices).   Sometimes I can get the tables retagged, but other times it can be quite frustrating.

Any more updates on this?

Can anyone suggest a website/training specifically for remediating using the CONTENT Panel and the TAGS Panel?  TIA.

Thank you all!

[kga-rti-kga]

I am using Office 365.

[L Wick]

There's a screenshot about halfway up this page, posted by Bevi Chagnon @ PubCom

Rather than using the "Save as Adobe PDF" option on the File menu, you need to click File, Save As (or Save a Copy), then in the dialog box where it lists the filename, file type, location, etc. change the file type to PDF. Office has it's own PDF converter built-in that tags the table headers properly.
Another issue I've noticed recently is that Acrobat no longer flags PDFs that don't contain any heading tags. However the service we use to monitor our website does flag PDFs without any heading tags, so I get to have conversations with people who are adamant their PDF passed the accessibility check, and try to explain to them that the checker is wrong.

[kga-rti-kga]

Thank you L Wick.   My apologies; I have added some edits to my wording.

When I use the "work around" method (from above in this thread by Beth), "Save As" (from the FILE menu in Word 365) and then select PDF as the file type, the table produces no errors; HOWEVER, my documents have no bookmarks.  

It seems like there is no consistency how Acrobat tags tables converted from Word.  The same is true when using Acrobat Autotag. 

Thank you for your input.