Accessible PDF Stamping

Many people and organizations put the extra care into their PDF documents to ensure they are usable by ALL humans, not just people with good vision and keyboard/mouse dexterity. What does this mean? It is often imperative documents be accessible due to accessibility codes and laws. So it must be very frustrating to have accessibility features removed by a PDF manipulation plugin! Unfortunately, the open-source PDF manipulation libraries I use for many of my plugins does not allow for robust or reliable PDF manipulation. Namely, TCPDI/TCPDF depends on being fed a syntactically correct PDF, and then because of the way objects are read flat into PHP memory during the process, certain PDF features in the stream are necessarily lost. Marking/passwording with TCPDI/TCPDF or FPDI/FPDF is lossy, no way around it.

However, the SetaPDF library from SetaSign works differently by parsing PDF objects and the stream into memory and working from there. In essence, it maps a PDF as it reads it, and doesn’t attempt to re-construct a PDF from a flat file. When it finds syntax errors, it can correct many of them on-the-fly, whereas other libraries usually stop when they encounter errors. More PDFs are successfully read, and well-read with SetaPDF, and none of their features need be lost. Until recently accessible PDFs lost their accessibility when a stamp was added to the PDF, because the stamp was not marked as an added “artifact” (for visually impaired readers to have understanding that something was “added” to the PDF).

Today I added an important feature to both EDDiStamper and WooStamper plugins, after a chat with someone from pdfa.org about PDF accessibility. Apparently there was a demo on the SetaSign website I hadn’t seen before, which allowed a watermark to be added to a PDF as an “artifact,” thereby maintaining the accessibility of an already-accessible PDF such that disabled users can still access and use the PDF document. This is an important feature for organizations which are forced by law to adhere to document accessibility standards and was easy enough to add. All it took was a heads up from a user it was missing, and it was added to core within 24 hours. I’d love to be able to run a comparison and see if an AI engine could have also done it that quickly, and how. Exciting times!

What Makes a PDF Accessible?

If you’ve built an accessible webpage, then you’d understand a good part of how to build an accessible PDF. Accessible PDFs are made much like accessible websites.

To start, PDF readers are looking for document structure, a heirarchy of titles/headings, and well-marked rows and columns, content, tables and lists. If a PDF is not well-tagged, the PDF reader will not find this structure and heirarchy. This might be okay for sighted/dexterous PDF users (since they do not usually interact with tags), but for others who rely on meaningful tagging to peruse a document, it can be a nightmare. Some PDF creation suites will attempt to automatically tag a PDF for you, but it is wise to return to the tags for a manual audit to make sure they are in order. Folks who understand HTML and proper HTML nesting will have an easier time with a manual audit.

Just like for websites, PDF images should be given alternative (alt) text.

Color contrast between text and background should be high (you can check color contrast at webaim.org).

Tools for PDF accessibility

The Adobe Acrobat Pro application can be used to create and verify accessible PDFs. Foxit also has an accessbility solution built into its PDF software. Similarly, Microsoft also offers tools for improving PDF accessibility.

How can you tell if your PDF is accessible? The tools linked above might tell you, but you can also check using the PDF Accessibility Checker tool to make sure. Having accessible PDFs not only means you are passing muster, but it also expands your audience and shows you care. Great work!