Blog Listing

Reviewing PDF/UA-related comments on the Section 508 NPRM

The comment period has closed on the US Access Board’s NPRM for the refresh of Section 508. This article reviews the 17 (out of 126) comments that mention PDF/UA. I’ve grouped them into four categories:

  • First are those who don’t speak to PDF/UA per se, but are focussed on other concerns (largely, the purchase-price of the standard).
  • Second are comments from those who clearly understand PDF/UA and/or the role of technical stanadards in general.
  • Third are comments which unfortunately misconstrue PDF/UA, most commonly by perceiving it as a competitor to WCAG 2.0 rather than a complement, and by referencing WCAG2ICT as a source of “additional guidance” for accessible PDF.
  • Fourth are other comments, including the one that gets my vote for best comment (thanks Ken Nakata for a great read!).

OK, let’s get started…

Concerns about PDF/UA’s cost

Several commenters are concerned about the cost and/or availability of PDF/UA, including Jennifer Horan, SSB and Carl Malamud. They will, I hope, be comforted (at least to some degree) by AIIM’s comment committing to publish PDF/UA as a US national standard, with a cost of $15.

Those supporting PDF/UA as a requirement for PDF documents

Not everyone likes what I have to say about PDF/UA, but I (unavoidably) have to count myself in this group; 2 of the 17 comments mentioning PDF/UA are mine. I’m not going to repeat myself in this post, but feel free to dive in if you are so inclined. The gist of my comments is to recommend that the Access Board adopt the following approach:

“WCAG 2.0 is required for all content. For PDF documents, PDF/UA is also required.”

The Consortium of Citizens with Disabilities, and the Association of Assistive Technology Act Programs (ATAP) make the same positive remarks about PDF/UA, stating:

“Including the PDF/UA-1 standards as being equivalent to WCAG 2.0 for a non-web document is incredibly valuable and will prove to be even more helpful as the PDF/UA-1 standard continues to find broader acceptance.” “[We] believe that the Access Board should create a clear nexus between the PDF/UA-1 standard and the PDF format.”

While I disagree that PDF/UA is “equivalent” to WCAG 2.0 (it’s not), CCD and ATAP are spot-on in arguing that standardizing on PDF/UA is “incredibly valuable.”

A comment from Jonathan Metz, who has participated in AIIM’s PDF/UA committee for several years. He argues that the Access Board should include requirements for AT. While he doesn’t mention it specifically, PDF/UA includes such requirements.

Those arguing for PDF/UA as an option (not a requirement) for PDF documents

Information Technology Industry Council (ITI)

A comment from the Information Technology Industry Council (ITI) argues for a clarification that would have PDF/UA plus four WCAG 2.0 Guidelines as an available option (but not a requirement) for PDF documents (the comment does note that such a model would be confusing).

ITI’s comment reveals a common misunderstanding: the assumption that PDF/UA is intended to replace or substitute for WCAG 2.0. This assumption is quickly dispelled by reviewing the introduction to PDF/UA, as I did in my testimony. Authors should use WCAG 2.0 to evaluate accessibility, but if the document to be produced is a PDF document, then the file creation software will need to use the applicable PDF accessibility standard as well.

ITI’s comments seem to focus on problems they suppose to be raised by the fact that PDF 2.0 is nearing the end of its development cycle – a concern that isn’t actually related to the utility (or lack thereof) of PDF/UA at all. If authors need some PDF 2.0 feature then it’s certainly true that they won’t be able to use that feature in a PDF/UA-1 context. However, there are very few features in PDF 2.0 that both impact accessibility and can’t be readily converted to PDF 1.7 in order to conform to PDF/UA-1.

The Section 508 regulations must target existing standards, and cannot incorporate by reference standards that do not yet exist. This is normal and expected – technology development and applicable regulations do not synchronize perfectly in all instances. The far more interesting question is: what’s the real impact from requiring PDF/UA-1 when the PDF industry is moving onto PDF 2.0? The answer is (and I say this as the chairman of the committee in question): not much. It’s likely that vendors won’t even begin to support these features until PDF/UA-2 is published in any event. Moreover, the more vendors concentrate on meeting the requirements of PDF/UA-1, the easier it will be for them to support WCAG 2.0. How we do encourage vendors to support PDF/UA-1? Clearly, by requiring it for all PDF documents.

Like some others, ITI recommends a reference to WCAG2ICT in the text of the regulations as it provides, they say, “guidance” relevant to PDF documents. This is a common mistake, one I’ve addressed towards the end of this review.


A comment from IBM makes the following claims:

  • As they see it, PDF/UA must be “updated” to meet all of the WCAG 2.0 criteria.
  • That an update to PDF/UA will be needed once PDF 2.0 is complete, as PDF/UA-1 will be “out of date” with PDF 2.0.

Like ITI, IBM misreads PDF/UA, missing the fact that PDF/UA is a complementary standard, meant to be used in conjunction with other standards, including WCAG 2.0. PDF/UA will never be “updated” to meet all of WCAG 2.0 because that’s not its objective.

IBM’s concerns regarding PDF/UA-1 becoming out of date once PDF 2.0 arrives are overblown. Any vendor who masters PDF/UA-1 will have no difficulty in supporting Section 508 regulations that require PDF/UA-1 while also supporting PDF 2.0 (even if not both at the same time).

Otherwise, IBM’s comment makes the same mistake about WCAG2ICT as does ITI, which I’ve addressed below.

Social Security Administration (SSA)

The comment from the SSA asks the Access Board to clarify that PDF/UA is optional, and not a requirement for PDF documents. Their stated reason:

“The PDF/UA format is not easy for subject matter experts to work with, is copyright protected, and has nearly a hundred references to ISO 32000 (the original PDF ISO standard).”

This comment would be more interesting if WCAG 2.0 offered a significant contrast to PDF/UA, at least to the first point. However, as those who are familiar with WCAG 2.0 know all too well, subject matter experts disagree daily and viscerally about how to apply WCAG 2.0 even to HTML, including such basics as whether or not WCAG 2.0 requires HTML documents to include <!DOCTYPE> metadata.

As to copyright protection, it’s indeed an unfortunate fact that ISO standards are copy-written documents owned by the ISO.  However, since PDF/UA is intended for software developers rather than authors this shouldn’t be a major problem.

The fact that PDF/UA includes references to ISO 32000 simply reflects the fact that PDF/UA is a “use” of PDF, not a complete file-format specification in its own right. One could just as easily complain that WCAG 2.0 requires an HTML developer to read the HTML specification in order to create an accessible web page.

SSA’s largest objection to requiring PDF/UA, however, is rooted in the idea that agencies should…

“…have single set of standards that apply to ALL electronic content….”

This is sensible, but SSA doesn’t say why this “set of standards” shouldn’t include PDF/UA. Since PDF/UA is something that happens “under the hood” no-one need be confused by it at all… unless it’s presented as an option to WCAG 2.0 instead of a complement, as SSA recommends, in which case it does indeed get confusing.

SSA then asserts:

“The WCAG guidelines are sufficient to communicate accessibility conformance, and the WCAG2ICT task force has bridged gaps between web content and electronic content.”

The claim that WCAG 2.0 is sufficient to ensure accessible PDF documents in all cases, as I pointed out in my testimony, is just wrong. Indeed, the reference to WCAG2ICT is itself a tacit acknowledgement that WCAG 2.0 is insufficient, as I discuss below.

 Adobe Systems

A comment from Adobe Systems makes the same arguments as are offered in ITI’s testimony (see above). However, since it’s Adobe’s comment it deserves a little extra scrutiny…

Adobe’s discussion of PDF/UA is headlined “Potential Problems with PDF/UA”. Let’s take the company’s statement one paragraph at a time.

Adobe states:

“PDF/UA-1 (ISO 14289-1) is a valuable standard for addressing accessibility in many PDF documents, but the Board should exercise caution in requiring PDF/UA for all PDF documents. PDF/UA-1 is applicable to PDF documents using the ISO 32000-1 version of PDF (PDF 1.7), but PDF/UA-1 is not able to address any accessibility improvements in the PDF format produced with future versions of the PDF format…”

I addressed the PDF 2.0 concern in my review of ITI’s comments. Adobe goes on to say:

“…nor does PDF/UA address all accessibility needs or types of content that are found in PDF files today.”

I agree entirely with this statement, but the problem only exists if one insists on PDF/UA as an alternative rather than a complement to WCAG 2.0. PDF/UA is, as I explain at the beginning of my testimony (and as Adobe appears to forget), a companion standard. It’s not designed or intended to cover all accessibility aspects for any content that may appear in a PDF document. PDF/UA is intended to work with other standards (such as WCAG 2.0) that do offer such coverage. Adobe continues:

“We are concerned that PDF documents be held to the same standard as other document types…”

I agree with this sentiment in general. PDF documents should be held to WCAG 2.0 standards, but WCAG 2.0, demonstrably, isn’t enough, as I’ve shown. At some level, Adobe seems to be aware that WCAG 2.0 doesn’t fully cover PDF, because they continue (emphasis added):

“…and feel that the use of WCAG 2.0 with additional information found in WCAG2ICT provides appropriate standards to ensure that PDF documents are accessible for people with disabilities.”

I discuss WCAG2ICT in the next section.

There’s only one other point I want to make with respect to Adobe’s testimony on PDF/UA. Adobe says:

“The Board may offer PDF/UA as an option for authors, but must also require additional criteria from WCAG 2.0 in order to ensure that all content types within PDF documents are sufficiently covered. Authors who use PDF/UA will find it a very helpful source of information for PDF documents that conform to ISO 32000-1 version of PDF, but WCAG 2.0 should be the primary requirement for conformance purposes.”

Here, Adobe suggests that authors will find PDF/UA a “…very helpful source of information.” This is incorrect.

PDF/UA is not intended in any way, shape or form for “authors”. It is a technical specification intended for software developers. It’s no more appropriate a source of information for authors than is OOXML, the specification for the .DOCX files used by Microsoft’s Word.

Software developers build PDF/UA into their products for the purpose of making or processing PDF documents. Authors should only encounter PDF/UA when they see it on the list of features supported by their software. Document authors will get the benefits of PDF/UA through the exact same mechanisms by which they interact with software to ensure WCAG 2.0 conformance.

How not to use WCAG2ICT

A problem common to the comments offered by ITI, IBM, SSA and Adobe is the invocation of WCAG2ICT as a source of “additional guidance” for making accessible PDF documents. There are several problems with using WCAG2ICT in this way. First, the document itself, as James White points out in his comment, states clearly:

“This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.”

As such, WCAG2ICT doesn’t belong in the Section 508 regulations at all, which require a stable document.

Regarding the claim that WCAG2ICT provides “additional guidance” for PDF documents (presumably, additional to WCAG 2.0): this is interesting because it’s a tacit acknowledgement that WCAG 2.0 alone is insufficient. But what is this “additional guidance”? Unfortunately, WCAG2ICT does not provide any “guidance” for PDF whatsoever.

For these two reasons, comments referencing WCAG2ICT in the context of PDF accessibility are destroying their own positions. If WCAG 2.0 is insufficient (as the reference to WCAG2ICT implies), and if WCAG2ICT does not include any provisions useful to implementing accessibility in PDF, then what are we to make of comments offering this advice?

Perhaps they want the reader to simply take their claim on faith?

Other comments

Ken Nakata, a 20 year veteran of the accessible content industry, gets my vote for the best comment submitted on the NPRM. Ken does not address PDF/UA specifically.  What he does do is focus on the notion that WCAG 2.0 by itself is sufficient to meeting the real-world needs of users, procurement officers, vendors and agencies. Rather than quote his remarks I strongly recommend that interested readers simply download and read them entirely.

Shawn Henry commented on the need for text customization support, pointing out that software providing this functionality in the PDF context isn’t yet available, which is not correct (VIP Reader and pdfGoHTML both provide access to text customization for well-tagged PDF).

These tools aren’t available to all (due to the cost of Adobe Acrobat), or to everyone’s liking, but it’s important to realize that any text customization that works with HTML may also be used on text extracted from accessible PDF documents. For this reason, broad-based PDF/UA adoption makes it more likely that advanced text customization options for PDF will emerge, precisely because PDF/UA conformance mandates high quality extractable text, the necessary prerequisite for successful text customization.

The State of Kansas provided a comment requesting the Access Board clarify in which cases PDF/UA is required.


  1. June 2, 2015 at 12:19

    “Authors should use WCAG 2.0 to evaluate accessibility, but if the document to be produced is a PDF document, then the file creation software will need to use the applicable PDF accessibility standard as well.”

    This is confusing to me. File creation software = source file software?

  2. June 6, 2015 at 13:00

    Thanks Duff for this review. As someone who has to explain all of this “standards-stuff” to mild-mannered, normal folks, I need a easy solution. All the average person really wants to know is what software to use to build/convert/save a PDF file in a good way so that people who are users of Assistive Technology can access the content. And they don’t want to hear that the have to purchase another expensive application (e.g., Adobe Acrobat XYZ) and then stand on their heads and wiggle their ears to make the file accessible. It should be that if you create your initial document in something like MS-Word, ensuring that it is fully accessible there, a simple click to “Save as PDF” should be all that is needed. Frankly, I don’t really care about what you call the “accessible version of PDF,” I just want to make it easy to create one or convert an already accessible digital document into one!

    Thanks again for this review.

  3. June 6, 2015 at 13:08

    @Doug – PDF “file creation” software is something included within some (not all) “source file software”.

    @John – I 100% agree with you! End users should not be subjected to this stuff whatsoever, except insofar as they need to use proper structure (ie, not manipulate font sizes to “represent” heading levels) and other things (like provide alt. text).

    PDF/UA is for software developers, not authors.. and it’s risible to suggest otherwise.

  4. June 9, 2015 at 23:03

    Hi Duff,

    I would like to correct your summarization of my comments and their truths.

    My comments actually say: “Today there are no PDF readers/viewers/user agents that provide the text customization that users need in order for PDF files to be accessible.” As I understand it, pdfGoHTML is a (free) Acrobat plug-in, and Acrobat is a (not free) authoring tool.

    My comments actually say: “if a PDF page contains form fields, users cannot “reflow” the page (from multiple columns to a single column), change font face, change leading/line spacing, or customize most other aspects of text display.” As I understand it, VIP Reader cannot open a PDF file with form fields.

    I appreciate that there have been some improvements in text customization functionality for PDF files. I stand by my statements that they are not sufficient for real world users.


  5. July 10, 2015 at 00:51

    Thank you for the clarification/correction, Shawn, and I appreciate your point.

    It is to be hoped that free tools to perform all the requested functionality will appear – the current tools demonstrate that no technical barriers exist.

    The best possible way to ensure text customization of PDF actually comes about in the mainstream is to require that PDF files conform to PDF/UA.

    Current-day browsers display PDF files without plugins already, and they are free. Having them process tagged PDF will allow them to “feed” PDFs into any HTML-driven customization process already present. Users would gain seamless access to PDF content displayed “their way”. But ONLY with very very high quality tagged PDF documents.

    If browsers understood PDF/UA you’d get exactly what you want in short order. And so I encourage you to support requiring PDF/UA wherever possible.

    Thanks for the comment.


Leave a Reply