WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/A accessibility

for

From: Duff Johnson
Date: Aug 10, 2011 7:33AM

Joseph,

On Aug 10, 2011, at 8:29 AM, Humbert, Joseph A wrote:

> I have to say that after reading your article that it seems to mislead the audience. The article makes many correct statements concerning PDF accessibility, except for:
>
> "And that's why we can safely and responsibly ignore reading order when considering accessibility in PDF."

This sentence merely sums up the argument in the article. If you found the rest of the piece accurate, then this sentence should come as no surprise.

> It is true that if a PDF is tagged correctly and the software used to consume can read the tags then the "logical reading order" will be correct, but as you even point out it prior emails, "'logical reading order' is the concept of interest". Therefore, some type of reading order, "logical" in this case, is very important.

Yes, of course. The entire point of the article is to distinguish between "LOGICAL reading order" (as specified via tags, essential to accessibility) and mere (traditional) "reading order" (specified by the sequence of objects in the content stream, essential to rendering).

The summary sentence you quote above refers only to "reading order" as traditionally defined in PDF - it does not refer to logical reading order.

> For many users of assistive technology (AT), the order in which the AT software reads the content is how the user perceives the logical reading order.

I would add here that if the AT software does not read the content in "logical reading order" (as defined by tags), then the software - not the file, or the file-format - has a problem.

> Headings and other tags help to improve a user's understanding of logical reading order and allow advanced users to navigate the document in their own "logical" reading order, but never the less reading order IS important.

...and I've never said otherwise. The point of the article is simply to point out where this "ordering" comes from. For AT purposes, it comes from the tags. For rendering purposes, it comes from the sequence of objects (traditional "reading order").

> Please don't get me wrong, the articles message about tagging PDF files and using software that supports creating accessible PDFs is wonderful. You seem to be well versed in accessibility issues. My interpretation of Ron's point is that "reading order" in some form is important.

Both you and Ron are 100% correct about this, and I've never disputed it. What seems to be missing from your understanding is the fact that (for these purposes) two distinguishable sorts of "order" can exist in PDF; logical and content. My point (again) is simply that in PDF it is LOGICAL order that matters for AT purposes while content order is all about painting stuff on the page.

> I may interject that I believe Ron's comments come from the point of view that many programs which create PDF/A documents do not automatically tag the document correctly, thus creating inaccessible PDFs.

Today, very few implementations for PDF understand tags. It seems that one of my missions in life to change that fact, in part, by writing articles attempting to explain the technical issues involved. It seems I have my work cut out for me!

> "Pagination" is also extremely important, particularly when a textbook or print article is being converted to a PDF. When this happens, my opinion is that the original "pagination" of the book/article should be preserved.

Whether or not the PDF resulting from the source file is paginated the same way as the source file isn't (strictly) an AT issue - it's an issue for any user, no?

> Ron, I'm not sure of your complaint with the PDF/A or PDF/UA specification is in terms of "pagination" so you will have to comment further.
> Back to the original question of the post, it seems as though the PDF/A specification does not have any accessibility limitations included in the specification.

That is a true statement.

> I have not read the full PDF/A specification so I cannot be 100% sure. Unfortunately, the software used to implement the specification in creation of a PDF/A file may produce accessibility issues that may have to be addressed manually.

That's true - PDF/A conformance by itself does not imply accessibility. There are actually three "conformance levels" in PDF/A...

PDF/A, conformance level "A" = tags required
PDF/A, conformance level "B" = no tags required
PDF/A, conformance level "U" = no tags required, extractable text required

> Please forgive me if I have misinterpreted something.

I appreciate any and all questions on this matter, and I thank you for them. I realize that PDF in general and PDF accessibility in particular are difficult, highly technical subjects, and (more interestingly) that the bulk of modern software is woefully behind the curve.

The purpose of PDF/UA (which the International Committee hopes to see published in Q1, 2012) is to improve that state of affairs by setting clear rules for software developers interested in creating or supporting accessible PDF.

Duff Johnson

US Committee for ISO/DIS 14289 (PDF/UA), Chair

p +1.617.283.4226
e <EMAIL REMOVED>
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com



>