WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/A accessibility

for

From: Humbert, Joseph A
Date: Aug 10, 2011 6:30AM


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."

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. 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. 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.

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. 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.

"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. 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. 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.

Please forgive me if I have misinterpreted something.

Joe Humbert, Assistive Technology and Web Accessibility Specialist
UITS Adaptive Technology and Accessibility Centers
Indiana University, Indianapolis and Bloomington
535 W Michigan St. IT214 E
Indianapolis, IN 46202
Office Phone: (317) 274-4378
Cell Phone: (317) 644-6824
<EMAIL REMOVED>
http://iuadapts.Indiana.edu/
-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff Johnson
Sent: Tuesday, August 09, 2011 6:58 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] PDF/A accessibility

On Aug 9, 2011, at 6:00 PM, Ron Stewart wrote:

> I think at this point that we may be talking past each other. Please
> put my comments in the context of an individual with a print related
> disability using PDF content in a modern educational environment.

...the target end-user (among others) for ISO 14289 (PDF/UA)...

> If you continue to purport that the current implementation of PDF/UA

A point of clarification... PDF/UA is an International Standard (ISO 14289). It is not an "implementation" - that word is typically used to refer to software itself, not to the rules that govern the behavior of software.

> is
> satisfactory from the position of persons with print related
> disabilities then I think you are in fact being disingenuous. You
> admitted there were shortcomings in our conversation at ATIA Chicago,
> but now you are saying that that is not the case?

Ron, that was almost a year ago, and quite frankly, I'm don't recall what shortcomings you and I were referring to at the time. There are shortcomings everywhere, including in PDF. PDF/UA attempts to address those shortcomings as they relate to accessibility. There are some things PDF/UA cannot address because they don't (yet) exist in PDF itself. Some of these items will be addressed in PDF/UA-2, which will be based on PDF 2.0. These are not, however issues that you've raised.

> Yes I am talking about content reading order, what other reading order
> is relevant to the effective consumption of PDF based content.

As I stated, "logical reading order" is the concept of interest - NOT "content reading order" which, as I explained, refers to the order in which the computer (as opposed to the user) reads the file.

These are two distinct concepts in PDF (and this fact is itself one of PDF's shortcomings), but nonetheless, the relevance (or lack thereof) of each concept to accessibility is clear in PDF/UA.

> This painting
> the page analogy that you and others continue to use does nothing to
> resolve the fundament issues related to effective consumption of
> complex PDF based content.

The purpose of the analogy is to make clear that for PDF accessibility we care about "logical reading order", not "content reading order". As such, I'm not really sure what point you are trying to make.

> Secondly the issue of maintenance of proper document pagination is
> ignored in your response.

Well, I tried to address your point in my response, but possibly I was too technical? Can you please offer a use-cae for the problem you mention so that I can better address it?

> For those of us who actually prepare and deliver fully accessible
> content these are not trivial issues, and to maintain that they are is
> problematic as this conversation moves forward.

Of course they aren't trivial... that's why it's taken over 6 years and 100 meetings to write PDF/UA! I am simply trying to understand your precise concerns in detail so that I might address them.

Thank you,

Duff Johnson.



> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
> Johnson
> Sent: Tuesday, August 09, 2011 2:17 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] PDF/A accessibility
>
> On Aug 9, 2011, at 4:45 PM, Ron Stewart wrote:
>
>> My apologies, but to purport a standard to be accessible when basic
>> elements of accessibility are not present is to be disingenuous.
>
> Before you go to "disingenuous" (that's fightin' words, sir) I think
> it would be best if we agreed on what we're talking about first, no?
>
>> I think I have
>> presented the issues clearly, what about reading order in PDF
>> documents
>
> What about reading order? PDF/UA specifies that the content of
> conforming documents shall be tagged in correct logical reading order.
> It also specifies that conforming PDF viewers shall be able to make
> use of that logical structure.
>
> If you are referring to content reading order (ie the order of objects
> in the content stream), that has to do with "painting" text, graphics,
> etc. on the page, and is not related to accessibility (which is why
> PDF/UA ignores the subject). "Reading order" in this context refers
> to the order in which the computer processes the file... not the end-user.
>
> Back when I worked at Appligent Document Solutions, I wrote an article
> in an attempt to describe this issue in detail.
>
> http://www.appligent.com/talkingpdf-eachpdfpageisapainting
>
> Yes... there's lots of software today that knows nothing of PDF tags
> and instead delivers text to the end-user in content reading order.
> Such software cannot conform to PDF/UA.
>
> Could you please clarify your concerns regarding PDF reading order in
> light of the above facts?
>
>> and
>> the presentation of proper pagination is not understood.
>
> PDF/UA requires that conforming software be able to read the
> PageLabels tree in order to establish the current logical page and
> thus to facilitate navigation based on that logical pagination. What is "not understood"?
>
>> I think I have been very clear, what is it that you do not understand
>> about these accessibility requirements?
>
> See above.
>
> Duff.
>
>
>
>> -----Original Message-----
>> From: <EMAIL REMOVED>
>> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
>> Johnson
>> Sent: Tuesday, August 09, 2011 1:36 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] PDF/A accessibility
>>
>> On Aug 9, 2011, at 4:29 PM, Ron Stewart wrote:
>>
>>> Duff, actually this is not true as you and I have discussed previously!
>>
>> Um... what isn't true?
>>
>>> There are some shortcomings in regards to accessibility in PDF/UA as
>>> it is currently structured.
>>
>> Ok, maybe (I'd like to hear more about that)... but the question was
>> about PDF/A, not PDF/UA....
>>
>>> Those are retention of reading order and pagination which are
>>> necessary components for producing accessible PDF documents.
>>
>> I guess I'm not clear on what you mean. Could you please explain further?
>>
>>> I
>>> find it to be continually problematic that the spokespeople for PDF
>>> accessibility to continue to ignore these inherent flaws in what is
>>> purported to be an "accessible" implementation.
>>
>> I look forward to learning what - in particular - you find so problematic.
>>
>> Thanks,
>>
>> 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
>>
>>
>>
>>> -----Original Message-----
>>> From: <EMAIL REMOVED>
>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
>>> Johnson
>>> Sent: Tuesday, August 09, 2011 1:09 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] PDF/A accessibility
>>>
>>> Jon,
>>>
>>>> Does anyone know if there are any particular accessibility
>>>> limitations to PDF/A documents compared with standard PDF documents
>>>
>>> There are none... unless you are relying on JavaScript to enhance
>>> accessibility in a PDF form, for example. (PDF/A prohibits JavaScript).
>>>
>>>> , and/or if there are
>>>> any special steps that should be taken to ensure PDF/A documents
>>>> are accessible?
>>>
>>> There are no "special" steps other than those steps required to make
>>> any PDF accessible (tagging). That said, a good workflow for
>>> accessible PDF/A documents would start with ensuring that you can
>>> readily convert the PDF to PDF/A before investing significant
>>> time/effort
>> into tagging.
>>>
>>>> The specific situation we're facing is converting fairly simple
>>>> Word docs (no images, no tables, no multiple columns) to PDF/A, but
>>>> any experience anyone has with this would be very helpful.
>>>
>>>
>>> 1) Ensure the files are properly structured prior to conversion
>>> (ie, focus on accessibility in the source document)
>>>
>>> 2) Convert to PDF using software that preserves that structure,
>>> converting it into tags in the PDF. Both Adobe Acrobat's "PDFMaker"
>>> plugin for Word
>>> (Windows) and Microsoft Office itself can do this.
>>>
>>> 3) Validate the tags, etc. per normal.
>>>
>>> 4) Convert to PDF/A once the file is otherwise finalized.
>>>
>>> I hope this helps.
>>>
>>> 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
>>>
>>>