Regarding the accessibility of PDF documents automatically generated from databases, XML, or other scalable systems, the question is often asked, “Is manual validation of the output PDF documents required to be sure that they are accessible and comply with PDF/UA?”.
While testing and verification is never a bad idea, the advantages of automation include speeding up processes and removing human error. Manually validating each generated PDF would be counterproductive. There are a few exceptions, but if certain criteria are met manual verification is not required.
First, your system has to be capable of producing accessible files. Being able to export tagged PDFs is the bare minimum; the tagging also has to be correct! If in doubt, refer to PDF Association resources such as the Tagged PDF Best Practice Guide: Syntax and the Matterhorn Protocol. Of course, keep in mind, too, that a file can be fully accessible and not be PDF/UA compliant. But, when it comes to PDF accessibility, PDF/UA is the “gold standard” and certainly worth trying to achieve!
Second, when using automated processes, a template is required. But you can’t use just any template. You’ll need to use a template that not only determines how the document will look visually, but you’ll also need to make sure that your template addresses all of the potential accessibility concerns, too.
Third, yes, you’ll need to test – during development and implementation. And make sure, when you’re testing your generated PDFs, you’re also testing those checkpoints that require manual verification. Now, I know, we started this article by saying you don’t need to test the PDFs and it seems like maybe I’m going back on my word. However, this is testing during development and implementation. Once you’re sure the files you’re creating are accessible then the system is free to run, and you don’t have to verify every document that is produced.
I hope this helps answer some questions around whether or not it's necessary to manually verify PDFs generated through automation.
In addition to his expertise with the CommonLook suite of tools for testing, creating and remediating PDFs, he is also well versed in accessibility standards including Section 508 (including the recent “refresh”), Health and Human Services (HHS), WCAG 2.0, WCAG 2.1, and PDF/UA. Paul is a member of the IAAP (International Association of Accessibility Professionals) and the PDF/UA Technical Working …