Copy link to clipboard
Copied
Very time consuming solution you found.
No need, can be easier and quikcker: Just do this in Acrobat: choose Tools, PDF Standards. Then click on Preflight. Make sure you see all fixes (In the menu it should say 'Acrobat Pro DC 2015' and not 'Essentials), the click on the most right icon that looks like a wrench; now use the search field to find 'Artifacts' fixes, there is one and it is called domething like 'Artifact all non-essential content'. Just run that. Done 🙂
Copy link to clipboard
Copied
Found the solution here: https://theaccessibilityguy.com/path-object-not-tagged-pdf-ua/
Copy link to clipboard
Copied
Those lines should be artifacts anyway, so another bug in InDesign
Copy link to clipboard
Copied
No it is not a bug, it is dependent on which standard you follow: WCAG2 for instance does not specify that the pdf has to be pdf/ua, and it is pdf/ua that says everything that is not 'essential' should be artefacted, like lines in a table. So there is a Preflight fix in Acrobat to check for pdf/ua and there are preflight fixes in Acrobat to artefact all non-essential content. But again, it is not an InDesign bug (InDesign has no pdf/ua export).
Copy link to clipboard
Copied
...WCAG2 for instance does not specify that the pdf has to be pdf/ua, and it is pdf/ua that says everything that is not 'essential' should be artefacted, like lines in a table.
By @Frans v.d. Geest
Just to clarify...
WCAG has absolutely nothing it can say about accessible PDFs: they are not the ones who determine accessible PDFs, and what they do recommend on the WCAG website is often wrong.
History:
[ Here's a quick overview of the history from Adobe: https://www.adobe.com/uk/acrobat/resources/document-files/pdf-types/pdf-ua.html ]
Therefore, WCAG has no authority about anything regarding PDF files. Let's keep them out of the conversation.
Although the tag structure looks similar between HTML and PDF tables, the actual coding of the files is drastically different. PDF documents are not HTML webpages; and PDFs require substantial programming to create them while HTML is just a mark-up language on content. Big difference!
With much admiration to my friend Frans,
—Bevi
(former PDF programmer, former web developer, former contributor to WCAG, and current delegate to the ISO committees for PDFs)
PS: And I agree that this is a bug in the export-to-PDF utility in InDesign. But there is an internal verbal battle behind the scenes of the committee and Adobe that I won't go into here. I doubt Adobe will fix this in our lifetimes.
Copy link to clipboard
Copied
Remember, that in the USA you have section508 compliance. In Europe we don't have that, there PDF is brought under what we call WCAG, for web and PDF, so hence we call those PDF's WCAG compliant. Also PAC2021 has a new tab: WCAG in the PDF checker. But yes, strictly speaking you are right Bevi 😉
Copy link to clipboard
Copied
Agim31170049247v Just for more info if you are interested:
Copy link to clipboard
Copied
Very time consuming solution you found.
No need, can be easier and quikcker: Just do this in Acrobat: choose Tools, PDF Standards. Then click on Preflight. Make sure you see all fixes (In the menu it should say 'Acrobat Pro DC 2015' and not 'Essentials), the click on the most right icon that looks like a wrench; now use the search field to find 'Artifacts' fixes, there is one and it is called domething like 'Artifact all non-essential content'. Just run that. Done 🙂
Copy link to clipboard
Copied
Frans' instructions are the best way to correct this problem. I've marked it as correct.
Just run it every time you're checking a PDF for accessibility.
Copy link to clipboard
Copied
PAC 2021 flags cell/table borders as needing tags, as well as other items.
All of this visual clutter must be artifacted for compliance, so ignore PAC's error on those items.