WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/A accessibility

for

From: Ron Stewart
Date: Aug 9, 2011 4:00PM

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.

If you continue to purport that the current implementation of PDF/UA 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?

Yes I am talking about content reading order, what other reading order is
relevant to the effective consumption of PDF based content. 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. Secondly the issue of maintenance of proper document pagination is
ignored in your response. 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.

Ron Stewart

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