ADA compliant PDFS versus HTML

[robdekoch]

Hi all,

I help maintain a large site with thousands of pdfs. In the past few months, we have only been posting ADA compliant PDFs. Since we don't create the majority of these (most are created by third party designers using In-Design), we rely on software (CommonLook) to remediate these documents. This process is really complicated and time-consuming. Lately our vendors have been providing us with compiant pdfs but we are still required to vet each document page-by-page.We are required to have a Commonlook generated MHT file for each pdf that shows the document has been run through Commonlook and meets all checkpoints.

My coworker and I were wondering if it would be less work-intensive (and more screen-reader friendly) to create ADA compliant HTML from these PDFs somehow. I have looked at some tools that convert PDFs to HTML and so far none are very helpful. It would be ideal to find a product (or features of Acrobat X) that converts these publications into ADA compliant html pages.

Is this a viable strategy? Are there better ways to approach this problem? Anyone have suggestions?

Thanks!

R. Dekoch

[George_Johnson]

Acrobat does have an accessibility check that you can use, but I don't know if it will suit your needs. My guess is that converting to HTML would not be reliable enough.

[BCM-MSY]

In Indesign, reorder ALL the objects on page using send to back, starting with the last object on page you wish read, continuing until the object you want read first in acrobat is sent to the back last in InDesign. The result is that the Reading order is correct in Acrobat. Obviously, any object additions to a page means re-ordering the whole page. Changing copy doesn't affect this. Also, the order of objects on a page has no relationship to the page structure. It appears that the object reading order is as objects are added to page. Ist added (and furthest back), 1st read, last added (nearest front), last read. Shuffling the objects in the Document Structure pane has no effect on this order (and vice-versa).

[hthomas18]

This was so helpful. I remember you having a more detailed comment related to this workflow but I can't seem to find it anymore. But thank you!

[Bevi Chagnon - PubCom.com · Accepted solution]

The original post in this discussion by @robdekoch goes back 12 years to 2011. A lot has changed in the accessibility field since then! Here's some updated info.

The best solution for compliant accessible PDFs is always to create a better InDesign source file from which the PDF is exported. Same for making PDFs from any other program, such as Word or PowerPoint. The source file — how it was engineered/constructed, the tags it specifies, how the reading orders are controlled, accessible hyperlinks, Alt Text, etc. — all affect the final exported PDF.

Making a better PDF from the start reduces your time and cost to check, review, test, remediate, and validate PDFs for compliance. We're talking minutes versus hours (and in some really horrific InDesign PDFs, days!).

How to make this happen? Authors, editors, and graphic designers all need specific training in making accessible documents. We've been teaching these methods and strategies for 20+ years, starting from soon after Sec. 508 was released. See courses at www.PubCom.com

RE: PDF checkers... All software checkers (and their online services, as well) use AI to run through a file and determine whether it passes compliance or not. But real accessibility compliance varies from file to file, depending upon the actual content.

Therefore, you must use more than these programs and services to determine compliance: you must have trained human checkers to determine many items:

• The logical reading orders shown in the Tag Tree and Architectural Reading Order (what's called "the order panel")
• Alt Text and Actual Text
• Whether Summaries and captions are required
• Footnotes
• Whether or not a hyperlink needs Alt Text

A couple of examples that came across my desk last week: and note that our remediators use all of the checking tools available, including Adobe Acrobat, CommonLook, PAC, and some other more obscure programs. And these instances passed all of these checkers...except the human checker!

• A client's Alt Text on a complex chart graphic was incorrect: it described something else that was completely unrelated to the chart.
• A client's Alt Text on charts didn't really describe the data nor what it implied. It was useless info.
• The tag reading order in a client's tech report was way out of whack and it was confusing to listen to the report in a screen reader because it didn't make sense.
• Last week (June 2023), Adobe's update to Acrobat and Adobe PDF Maker had a major bug that swapped the Alt Text for every graphic in a Word.docx and replaced it with alpha-numeric code gibberish. Read more about the bug and a workaround here: https://community.adobe.com/t5/acrobat-discussions/new-bug-in-pdf-maker-removes-alt-text/m-p/1385104...  Note, Adobe started working on a fix as soon as they learned about the bug.

Just pointing out that all of these errors passed all of the automatic checking software programs our shop uses.

Whatever workflow, strategies, and procedures you put into place,  keep in mind that there isn't a 'one size fits all' solution for all PDF files.

We have some free blogs that cover these very detailed topics:

• Which standard to use for different types of files and content: https://pubcom.com/blog/standards/wcag-pdf/index.shtml
• Workaround for the PDF Maker bug: https://pubcom.com/blog/tutorials/ms-office/export-pdf/index.shtml
• Accessibility laws in the US, and what to specify in your accessibility requirements: https://pubcom.com/blog/standards/managing-a11ly_1/index.shtml
• Management: a Sec. 508 strategy: https://pubcom.com/blog/2018_06-01/508-strategy.shtml

Best to every one!

[Creamer Training]

Also, some excellent books and cheat sheets are available here:

https://pubcom.com/books/index.shtml