I'm glad there is a PDF/UA. It does not introduce substantially new requirements beyond WCAG, except those which after careful consideration, investigation and wide review, were made best practices rather than requirements in WCAG, such as nested headings. PDF/UA doesn't have an accessibility supported section and therefore requires marking as artifacts EVERY path, even ones that are ignored by assistive technology. There can be thousands of these in a document which could result is significant cost to remediate issues that are not any trouble to assistive technology. This should be addressed in the next version of the PDF/UA.

I have run into students who took courses on PDF accessibility and WCAG, who think a PAC pass is required by PDFs that conform to WCAG.

Organizations should understand that the PAC makes requirements that are distinct from the WCAG.

PDF/UA is the basis of the PAC, and there are some requirements in the PDF/UA that are not required by WCAG and vice versa. There may be a bit of politics behind the PDF/UA and WCAG, but that is peripheral to the issue of what the law requires in jurisdictions where WCAG is required.

PDF/UA conformance as measured by the PAC may or may not provide WCAG conformance. PAC is a useful tool, but only that. For those who do not know what to ignore, it adds quite a bit of work requiring things not necessary, adding time and cost to PDF remediation that is not required under the law. Meanwhile it cannot measure some things that need a manual check. Here are some examples.

• It can report thousands of paths that "need to be" marked up artifacts, which screen readers long ago learned to ignore.
• It requires nested headings which are not required by WCAG.
• It requires all footers to be marked up as artifacts, without requiring that information to be available to non sighted users in another way.
• It can't check LiveCycle forms.

The PAC cannot measure some WCAG requirements which need to be manually checked. A simple example is a picture of a CAT with alt="dog". PAC will pass it, but it fails WCAG because the alt does not provide the "equivalent purpose" as the image.

So in short: Sure, use the PAC to help ferret out errors, but don't be alarmed when it reports 16,000 "path" errors in your document, and make sure to evaluate the other WCAG issues not covered in the PAC, such as accurate alt text, and ensure the footer information is available elsewhere, such as the cover page, or section page, if the footer is marked as an artifact. Ensure your page numbers in the document match the page numbers in the PDG pages panel.

An interesting discussion is here.

Feel free to comment on Twitter @davidmacd

Author information:

David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.