WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/A accessibility

for

From: Duff Johnson
Date: Aug 10, 2011 10:48AM

Ron,

I'm sorry you feel that way, and I apologize if I've contributed to a misunderstanding.

I've never said that PDF (or PDF/UA) is "fundamentally broken" - if it were, then I wouldn't have wasted the last 11 years working on the subject, including 6 years as chair of the US Committee.

Feel free to contact me offline (contact information below) so that I can have a chance to better understand and address (if I can) your concerns.

Once I understand your concerns in detail, I will be delighted to take them to the PDF/UA Committee so that we can improve the standard accordingly.

You are also welcome to join the US Committee for PDF/UA yourself, if it's of interest to you.

sincerely,

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



On Aug 10, 2011, at 12:22 PM, Ron Stewart wrote:

> I have better things to do with my time than continue this meaningless
> debate. PDF/UA is fundamentally broken for folks with a variety of print
> related disabilities and you have acknowledged that fact in several posts.
> Unless you are actually willing to admit this then any further conversation
> is also fundamentally broken.
>
> Ron Stewart
>
> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff Johnson
> Sent: Tuesday, August 09, 2011 3: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
>>>>
>>>>