WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/A accessibility

for

From: Duff Johnson
Date: Aug 9, 2011 4:57PM

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