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!).
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.
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.
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.
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.
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.
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.
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's discussion of PDF/UA is headlined "Potential Problems with PDF/UA". Let's take the company's statement one paragraph at a time.
I discuss WCAG2ICT in the next section.
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.
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?
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.
Previous: Previous post: Has EPUB peaked?
This is confusing to me. File creation software = source file software?
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!
@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.
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.
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.