Copy link to clipboard
Copied
I make a lot of pdf files with tables for a client and they should all be accessible. When i export the tables to PDF, all the cell lines convert to paths in the PDF Content panel- and this is not compliant with the wcag 2.1 standards. Is it possible to artifact all the lines in the cells when exporting to PDF.
- Jakob.
Copy link to clipboard
Copied
If you're using the current version of Adobe InDesign (and it's built-in PDF export utility), there's no need to do this; tables export correctly and are compliant (in terms of borders/paths).
You might be confusing the different panels in Acrobat. Per the PDF/UA-1 accessibility standards (ISO 14289-1 https://www.iso.org/standard/64599.html), it's the Tags Panel that controls the accessibility through tags and structure (or reading order).
The Content Panel shows every computer object in the file, so yes, it would show the cell borders as paths. But the paths are not visible or tagged in the Tags Panel so they are, by default, artifacted and not recognized by assistive technologies (AT).
FYI, PDF files are evaluated for accessibility compliance with the PDF/UA-1 standard. WCAG was developed specifically for web content that is HTML-based, not PDF.
Although the 2 standards "harmonize" on the core principals of accessibility and many of the tags are similar, the file formats themselves are vastly different. Some people think of PDF/UA as "WCAG designed for PDFs" and they're not too far off with that comparison.
See the example below: when voiced by a screen reader, the table is read correctly without any "path" or <Figure> tags.
A table created in InDesign CC:2019
The exported PDF in Acrobat's Tag Panel: no "path" or <Figure> tags.
The exported PDF in Acrobat's Content Panel shows all elements in the PDF, including "path".
Hope this helps.
—Bevi Chagnon
Accessibility consultant
PubCom.com | Technologists for Accessible Design + Publishing
Copy link to clipboard
Copied
WCAG was developed specifically for web content that is HTML-based, not PDF.
I was on the WCAG working group, and from WCAG 2.0 onwards, the standard is intended for all types of web content, not just HTML. The standard only describes the result and is technology-independent. Separate techniques documents explain how to achieve the standards in different technologies, including the PDF Techniques for WCAG 2.0.
Copy link to clipboard
Copied
@yhoitink, I was on the WCAG 1 original working group, and am a former PDF programmer and HTML developer. I'm now on the PDF/UA ISO committee.
I'm attempting to clear up some misinformation about accessible PDFs.
There were many problems when WCAG claimed a while back that "WCAG is device neutral" and WCAG is the standard for all digital media regardless of whether it was HTML or not.
It was a catchy phrase that everyone repeated, without really thinking about the technologies involved.
PDF and Office files are independent document files that are very different from HTML in countless ways, but they still share the overriding goals of WCAG and POUR: make the content accessible. Document files require programming, which is a very different task from marking up HTML content with tags.
Same with EPUB files: although similar to HTML, they have their own properties and features — and their own EPUB standard for accessibility.
But there's a more important legal aspect when WCAG tried to define accessibility for a file format that was owned and maintained by another entity: Infringement of patents and copyright.
The PDF file format was initially developed by Adobe in the late 1980s and was released in the early 1990s. At that time, only Adobe brand software could create and read PDFs: it was a proprietary technology from start to finish.
Fast forward to 2008, when Adobe donated the PDF file format and its matching PDF standard (but not the Acrobat software) to the ISO to maintain it in the public interest. Several related events happened about the same time:
Therefore, WCAG can't make up its own standard for accessible PDFs.
The reference cited above — PDF Techniques for WCAG 2.0. — has so many errors and missing requirements that WCAG should be embarrased for misleading the accessibility community. And it's grossly out of date. It cites Acrobat 9 (circa 2008 — before the first PDF/UA-1 standard was released in 2012) and Word 2010 (circa 2010, which lacked most of the tools needed for accessibility). And WCAG's revised PDF guidelines in WCAG 2.1 are not much better, although I note that the language suggesting that all PDFs follow WCAG has now been removed.
It's such shameful behavior and doesn't help either the publishing community or people with disabilities.
If any WCAG member wants to contribute to the PDF/UA standards, then join the PDF Association and the technical committee, and come work with us. Several of us on PDF/UA have WCAG backgrounds, and I can truthfully say that in most of our meetings the question "how does WCAG handle this" comes up. We use the goals of WCAG to produce "real" functional accessibility standards for PDFs.
And if you want to learn more about how to make accessible PDFs, then I welcome you into any of my classes and can give WCAG members a professional courtesy discount. Just contact me directly.
Copy link to clipboard
Copied
Thanks Bevi, it's good to know that the screen reader reads the table correctly.
But even though the screen reader reads the file correctly, the pdf will not pass the PAC 3 checker and that is what my client wants. I can remediate the pdf file in Acrobat and artifact all the paths, but I wanted to know if there is a way to do this from InDesign. is there a script for this maybe?
All the Paths will not pass the PAC 3 checker.
Copy link to clipboard
Copied
PAC3, CommonLook, and other accessibility checkers are created by commercial companies. There is no checker that is made by the ISO committee itself, which in my opion would be the defacto "one" opinion that would matter.
Although these companies sit on the ISO standards committee with me, we all at times interpret the standards slightly differently. There are several areas of PAC3 that are flagged as errors when, in my firm's opinion, they actually aren't and this is one.
The PDF/UA standard says all viable content must be in the tag tree, tagged with the appropriate tag, and in a logical reading order in the tag tree. The cell borders aren't in the tag tree for AT to access.
Checking the file with real screen reading software, the borders are not announced. Nor do they appear in the Order panel, either. These borders only appear in the Content Panel which shows every single item in the document file, whether it's viable content or artifacted or neither.
In our shop, this is a "non-error" error. I'd prefer that PAC 3 give us a better feedback on these borders, something like:
Keep in mind that all of the accessibility checkers are not the standard itself, but merely someone's interpretation of the standard.
From a practioner's viewpoint...
If my client insisted on perfect compliance with PAC 3:
And in my shop, we use all 3 accessibility checkers as well as a checklist that has items not covered by any of them. None of the software checkers catch everything or evaluate the same items.
Copy link to clipboard
Copied
Quote: << is a way to do this from InDesign. is there a script for this maybe? >>
No, InDesign's PDF export utility is in control of this. Ideally, the PDF converter SHOULD be artifacting these borders so make a request for them to do this at http://www.indesign.uservoice.com
You might try a commercial plug-in for InDesign, Made To Tag, by Axaio Software (also on the ISO committee).
Copy link to clipboard
Copied
Hi Bevi
I appreciate this thread relates to InDesign and dates back to 2019, but I have been experiencing a similar issue (ongoing) with numerous PDFs with tables generated from Word using the Acrobat plugin, where paths show in the tags tree and then error in PAC for PDF/UA compliance. Despite searching for and using various preflight 'fixes' in Acrobat Pro (2019 and 2022 versions), these paths cannot seem to be changed to artifact. Are you aware of a solution to this issue that can be applied natively in Acrobat? I was under the impression this could be done in a later version of Acrobat, but I can't see how/where. Is the only solution to use Commonlook or similar as a plugin to Acrobat to address this? I've attached a couple screen grabs to illustrate. Thanks - Paul
Copy link to clipboard
Copied
@Paul-BT, your screen captures look like an older version of PDF Maker was used.
<P>PathPathPathPath was a bug in the utility that was corrected about a year ago.
PDF Maker is part of Acrobat Standard or Pro. When Acrobat is installed, it adds the PDF Maker plug-in to MS Office applications. So if you want the latest PDF Maker, you must update Acrobat itself.
Check your vesion of Acrobat (Help / About Acrobat) against Adobe's release list:
https://helpx.adobe.com/acrobat/release-note/release-notes-acrobat-reader.html
Note that the newest release was just a few days ago (January 2023) and has a revamped user interface. Many don't like the layout change, but you can revert back to the traditional interface from the File menu (now known as the hamburger menu in the upper left). But PDF Maker isn't affected by which interface you use. https://helpx.adobe.com/acrobat/using/whats-new/2023-january.html
Update to a more recent Acrobat and I expect that the <P>PathPathPath problem will be gone!
As an added measure to take, run Acrobat Pro's Preflight to identify and correct many of these errors (and others).
Hope this helps.
Copy link to clipboard
Copied
Hi Bevi
Typically, our IT department had rolled out a later version of Acrobat yesterday and I hadn't created a new PDF using the PDF Maker at the point I posted. Having just created a new PDF from an old file that contained a large portion of tables, the '<P>PathPathPathPath' issue has indeed been resolved!
I have been aware of the Preflight 'Fix' option for quite some time and have used it extensively with both the 2015 Profiles and Standards options. Whilst they do fix a lot of potential issues, neither option seems to fix the Path issues on older/existing PDF files that could be remedied without having to resort to the source file and remake. One of my files has 1000+ paths, so would be too time consuming to change to artifact in the content panel.
I have tested PDFs with NVDA and the paths don't get announced anyway, so I assume it perhaps doesn't warrant spending time fixing an issue that isn't really an issue? If that's the case, it's a shame PAC 3/2021 doesn't ignore them if they don't present a PDF/UA failure for assistive technologies.
Thanks again - Paul
Copy link to clipboard
Copied
I have tested PDFs with NVDA and the paths don't get announced anyway, so I assume it perhaps doesn't warrant spending time fixing an issue that isn't really an issue? If that's the case, it's a shame PAC 3/2021 doesn't ignore them if they don't present a PDF/UA failure for assistive technologies.
By @Paul-BT
@Paul-BT, remember that the companies that own the PDF testing software or services have something else to sell you — software or services to correct the errors they find.
The same programmers that write PAC also create Axes4 and have remediation services. The same company that creates PDF Validator also creates CommonLook and has remediation services.
If you've thoroughly tested your files with at least NVDA and JAWS, and find that the PathPathPath is not voiced, then I think you're safe to let the file go public. But do check it every year or so: the PDF/UA standard itself is being updated and assistive technologies will evolve afterwards. Those PathPathPaths could very well be vocalized later down the road.
One workaround we use at our shop: when we have a legacy PDF from an older Word.docx that's filled with PathPathPath, we open the Word file in the latest version of Word 365 and re-export a new PDF using the latest PDF Maker or the built-in MS Word File / Save As / PDF conversion utility.
That usually gets rid of any residual PathPathPath crapahola in the new PDF, not just around table cells, but also in hyperlink underlines and borders around text boxes and paragraphs. We find it's often the fastest way to correct an older PDF.
Copy link to clipboard
Copied
@Bevi Chagnon - PubCom.com - Thanks again. I have had similar thoughts about the software and services from these companies, so it's good to get your confirmation I wasn't wrong. Sadly, we don't have access to Jaws where I work, only NVDA, but we do have 365 and yes, I was thinking that the simplest method to remedy the PathPathPath issue would indeed be to create new PDFs from the older files. Good to know I'm on the right 'path'! (ahem)
Copy link to clipboard
Copied
Just make sure that the "path" you're on doesn't get artifacted!
<grin>
Find more inspiration, events, and resources on the new Adobe Community
Explore Now