WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: PDF/A accessibility

for

Number of posts in this thread: 15 (In chronological order)

From: Jon Mires
Date: Tue, Aug 09 2011 1:51PM
Subject: PDF/A accessibility
No previous message | Next message →

Hi all,

Does anyone know if there are any particular accessibility limitations to
PDF/A documents compared with standard PDF documents, and/or if there are
any special steps that should be taken to ensure PDF/A documents are
accessible?

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.

Thanks in advance,
Jon

From: deborah.kaplan@suberic.net
Date: Tue, Aug 09 2011 2:09PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

We've had trouble creating accessible PDF/A documents, but for the life of me I can't remember why off the top of my head, so I would love to see what other people have to say about this.

-Deborah

From: Duff Johnson
Date: Tue, Aug 09 2011 2:15PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com

From: LSnider
Date: Tue, Aug 09 2011 2:30PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

They actually make more accessible documents because the PDF-Archival format
is more stringent...You need your alts for example, otherwise you will not
get a PDF-A. One tip, always use the preflight and look to see which you
want, PDF-A 1a or 1b. I have found that 1b is easier, but still strict. Do
the usual stuff like headings and tagging, same as PDF....

Hope that helps.

Lisa

On Tue, Aug 9, 2011 at 12:48 PM, Jon Mires < = EMAIL ADDRESS REMOVED = > wrote:

> Hi all,
>
> Does anyone know if there are any particular accessibility limitations to
> PDF/A documents compared with standard PDF documents, and/or if there are
> any special steps that should be taken to ensure PDF/A documents are
> accessible?
>
> 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.
>
> Thanks in advance,
> Jon
>

From: Ron Stewart
Date: Tue, Aug 09 2011 2:36PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

Duff, actually this is not true as you and I have discussed previously!

There are some shortcomings in regards to accessibility in PDF/UA as it is
currently structured. Those are retention of reading order and pagination
which are necessary components for producing accessible PDF documents. 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.

Ron Stewart

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com

From: Ron Stewart
Date: Tue, Aug 09 2011 2:48PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

My apologies, but to purport a standard to be accessible when basic elements
of accessibility are not present is to be disingenuous. I think I have
presented the issues clearly, what about reading order in PDF documents and
the presentation of proper pagination is not understood.

I think I have been very clear, what is it that you do not understand about
these accessibility requirements?

Ron Stewart

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> t http://www.twitter.com/duffjohnson
> w http://www.duff-johnson.com
>
>

From: Duff Johnson
Date: Tue, Aug 09 2011 2:54PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> t http://www.twitter.com/duffjohnson
> w http://www.duff-johnson.com
>
>

From: Duff Johnson
Date: Tue, Aug 09 2011 3:18PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> t http://www.twitter.com/duffjohnson
> w http://www.duff-johnson.com
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> t http://www.twitter.com/duffjohnson
>> w http://www.duff-johnson.com
>>
>>

From: Ron Stewart
Date: Tue, Aug 09 2011 4:00PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> t http://www.twitter.com/duffjohnson
> w http://www.duff-johnson.com
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> t http://www.twitter.com/duffjohnson
>> w http://www.duff-johnson.com
>>
>>

From: Duff Johnson
Date: Tue, Aug 09 2011 4:57PM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> t http://www.twitter.com/duffjohnson
>> w http://www.duff-johnson.com
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> t http://www.twitter.com/duffjohnson
>>> w http://www.duff-johnson.com
>>>
>>>

From: Humbert, Joseph A
Date: Wed, Aug 10 2011 6:30AM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
http://iuadapts.Indiana.edu/
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> t http://www.twitter.com/duffjohnson
>> w http://www.duff-johnson.com
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> t http://www.twitter.com/duffjohnson
>>> w http://www.duff-johnson.com
>>>
>>>

From: Duff Johnson
Date: Wed, Aug 10 2011 7:33AM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
t http://www.twitter.com/duffjohnson
w http://www.duff-johnson.com



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> t http://www.twitter.com/duffjohnson
>>> w http://www.duff-johnson.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>>> t http://www.twitter.com/duffjohnson
>>>> w http://www.duff-johnson.com
>>>>
>>>>

From: Ron Stewart
Date: Wed, Aug 10 2011 10:21AM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> t http://www.twitter.com/duffjohnson
>> w http://www.duff-johnson.com
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> t http://www.twitter.com/duffjohnson
>>> w http://www.duff-johnson.com
>>>
>>>

From: Duff Johnson
Date: Wed, Aug 10 2011 10:48AM
Subject: Re: PDF/A accessibility
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> t http://www.twitter.com/duffjohnson
>>> w http://www.duff-johnson.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>>> t http://www.twitter.com/duffjohnson
>>>> w http://www.duff-johnson.com
>>>>
>>>>

From: Duff Johnson
Date: Wed, Aug 10 2011 12:03PM
Subject: Re: PDF/A accessibility
← Previous message | No next message

All,

Karen McCall has pointed out to me that confusion on the question of PDF "reading order" may be due in part to my failure to use a term that may be more familiar to the AT community: "raw print stream".

So... in brief, here's a translation of PDF terms - I hope this clarifies things....

"reading order" = the raw print-stream (interesting for rendering)

"logical reading order" = the sequence (and nesting) of PDF tags (interesting for accessibility)

In the absence of tags (or software capable of reading tags), AT users are typically stuck with the raw print stream, which (naturally) leaves them unimpressed (at best) or utterly frustrated (the typical case).

The solution:

1) The software used to consume PDFs (both the PDF reading software itself and the AT) must understand PDF tags.

2) The PDF in question must be tagged correctly, just as images must have alt. text, tables must include valid table structure, etc, etc.

I hope this helps.

Duff Johnson

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

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



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."
>
> 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 ADDRESS REMOVED =
> http://iuadapts.Indiana.edu/
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>> t http://www.twitter.com/duffjohnson
>>> w http://www.duff-johnson.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
>>>> t http://www.twitter.com/duffjohnson
>>>> w http://www.duff-johnson.com
>>>>