WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/A accessibility

for

From: Karlen Communications
Date: Sep 7, 2011 4:42AM

This is one of the reasons it is available. For many untagged documents it
can provide the best rendering of content depending on how complicated the
layout is and what the raw print stream is. It is also why we have the
option for left to right, top to bottom for untagged documents...or
'randomly tagged documents (documents where Tags have been added but not
verified or corrected).

In some documents when you either have to use OCR then the "virtual Tags" or
just the "virtual Tags" the character spacing is off and words do run
together. Being able to get a different view of the content often helps in
decoding/reading content.

Cheers, Karen


-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of
<EMAIL REMOVED>
Sent: September-07-11 2:32 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] PDF/A accessibility

this is interesting because in many instances I find that the use of the raw
print stream provides the most accurate reading with JAWS in many documents.

In many documents words will be ran together possibly caused by how JAWS may
be viewing the document when reading.
Chuck
----- Original Message -----
From: "Duff Johnson" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Wednesday, August 10, 2011 11:04 AM
Subject: Re: [WebAIM] PDF/A accessibility


> 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 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 REMOVED>
>> http://iuadapts.Indiana.edu/
>> -----Original Message-----
>> From: <EMAIL REMOVED>
>> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
>> Johnson
>> Sent: Tuesday, August 09, 2011 6:58 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] PDF/A accessibility
>>
>> On Aug 9, 2011, at 6:00 PM, Ron Stewart wrote:
>>
>>> I think at this point that we may be talking past each other.
>>> Please put my comments in the context of an individual with a print
>>> related disability using PDF content in a modern educational
environment.
>>
>> ...the target end-user (among others) for ISO 14289 (PDF/UA)...
>>
>>> If you continue to purport that the current implementation of PDF/UA
>>
>> A point of clarification... PDF/UA is an International Standard (ISO
>> 14289). It is not an "implementation" - that word is typically used
>> to refer to software itself, not to the rules that govern the
>> behavior of software.
>>
>>> is
>>> satisfactory from the position of persons with print related
>>> disabilities then I think you are in fact being disingenuous. You
>>> admitted there were shortcomings in our conversation at ATIA
>>> Chicago, but now you are saying that that is not the case?
>>
>> Ron, that was almost a year ago, and quite frankly, I'm don't recall
>> what shortcomings you and I were referring to at the time. There are
>> shortcomings everywhere, including in PDF. PDF/UA attempts to
>> address those shortcomings as they relate to accessibility. There are
>> some things PDF/UA cannot address because they don't (yet) exist in
>> PDF itself. Some of these items will be addressed in PDF/UA-2, which
>> will be based on PDF 2.0. These are not, however issues that you've
raised.
>>
>>> Yes I am talking about content reading order, what other reading
>>> order is relevant to the effective consumption of PDF based content.
>>
>> As I stated, "logical reading order" is the concept of interest - NOT
>> "content reading order" which, as I explained, refers to the order in
>> which the computer (as opposed to the user) reads the file.
>>
>> These are two distinct concepts in PDF (and this fact is itself one
>> of PDF's shortcomings), but nonetheless, the relevance (or lack
>> thereof) of each concept to accessibility is clear in PDF/UA.
>>
>>> This painting
>>> the page analogy that you and others continue to use does nothing to
>>> resolve the fundament issues related to effective consumption of
>>> complex PDF based content.
>>
>> The purpose of the analogy is to make clear that for PDF
>> accessibility we care about "logical reading order", not "content
>> reading order". As such, I'm not really sure what point you are trying
to make.
>>
>>> Secondly the issue of maintenance of proper document pagination is
>>> ignored in your response.
>>
>> Well, I tried to address your point in my response, but possibly I
>> was too technical? Can you please offer a use-cae for the problem
>> you mention so that I can better address it?
>>
>>> For those of us who actually prepare and deliver fully accessible
>>> content these are not trivial issues, and to maintain that they are
>>> is problematic as this conversation moves forward.
>>
>> Of course they aren't trivial... that's why it's taken over 6 years
>> and
>> 100 meetings to write PDF/UA! I am simply trying to understand your
>> precise concerns in detail so that I might address them.
>>
>> Thank you,
>>
>> Duff Johnson.
>>
>>
>>
>>> -----Original Message-----
>>> From: <EMAIL REMOVED>
>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
>>> Johnson
>>> Sent: Tuesday, August 09, 2011 2:17 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] PDF/A accessibility
>>>
>>> On Aug 9, 2011, at 4:45 PM, Ron Stewart wrote:
>>>
>>>> My apologies, but to purport a standard to be accessible when basic
>>>> elements of accessibility are not present is to be disingenuous.
>>>
>>> Before you go to "disingenuous" (that's fightin' words, sir) I think
>>> it would be best if we agreed on what we're talking about first, no?
>>>
>>>> I think I have
>>>> presented the issues clearly, what about reading order in PDF
>>>> documents
>>>
>>> What about reading order? PDF/UA specifies that the content of
>>> conforming documents shall be tagged in correct logical reading order.
>>> It also specifies that conforming PDF viewers shall be able to make
>>> use of that logical structure.
>>>
>>> If you are referring to content reading order (ie the order of
>>> objects in the content stream), that has to do with "painting" text,
>>> graphics, etc. on the page, and is not related to accessibility
>>> (which is why PDF/UA ignores the subject). "Reading order" in this
>>> context refers to the order in which the computer processes the
>>> file... not the end-user.
>>>
>>> Back when I worked at Appligent Document Solutions, I wrote an
>>> article in an attempt to describe this issue in detail.
>>>
>>> http://www.appligent.com/talkingpdf-eachpdfpageisapainting
>>>
>>> Yes... there's lots of software today that knows nothing of PDF tags
>>> and instead delivers text to the end-user in content reading order.
>>> Such software cannot conform to PDF/UA.
>>>
>>> Could you please clarify your concerns regarding PDF reading order
>>> in light of the above facts?
>>>
>>>> and
>>>> the presentation of proper pagination is not understood.
>>>
>>> PDF/UA requires that conforming software be able to read the
>>> PageLabels tree in order to establish the current logical page and
>>> thus to facilitate navigation based on that logical pagination. What
>>> is "not understood"?
>>>
>>>> I think I have been very clear, what is it that you do not
>>>> understand about these accessibility requirements?
>>>
>>> See above.
>>>
>>> Duff.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: <EMAIL REMOVED>
>>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
>>>> Johnson
>>>> Sent: Tuesday, August 09, 2011 1:36 PM
>>>> To: WebAIM Discussion List
>>>> Subject: Re: [WebAIM] PDF/A accessibility
>>>>
>>>> On Aug 9, 2011, at 4:29 PM, Ron Stewart wrote:
>>>>
>>>>> Duff, actually this is not true as you and I have discussed
>>>>> previously!
>>>>
>>>> Um... what isn't true?
>>>>
>>>>> There are some shortcomings in regards to accessibility in PDF/UA
>>>>> as it is currently structured.
>>>>
>>>> Ok, maybe (I'd like to hear more about that)... but the question
>>>> was about PDF/A, not PDF/UA....
>>>>
>>>>> Those are retention of reading order and pagination which are
>>>>> necessary components for producing accessible PDF documents.
>>>>
>>>> I guess I'm not clear on what you mean. Could you please explain
>>>> further?
>>>>
>>>>> I
>>>>> find it to be continually problematic that the spokespeople for
>>>>> PDF accessibility to continue to ignore these inherent flaws in
>>>>> what is purported to be an "accessible" implementation.
>>>>
>>>> I look forward to learning what - in particular - you find so
>>>> problematic.
>>>>
>>>> Thanks,
>>>>
>>>> Duff Johnson
>>>>
>>>> US Committee for ISO/DIS 14289 (PDF/UA), Chair
>>>>
>>>> p +1.617.283.4226
>>>> e <EMAIL REMOVED>
>>>> t http://www.twitter.com/duffjohnson
>>>> w http://www.duff-johnson.com
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: <EMAIL REMOVED>
>>>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Duff
>>>>> Johnson
>>>>> Sent: Tuesday, August 09, 2011 1:09 PM
>>>>> To: WebAIM Discussion List
>>>>> Subject: Re: [WebAIM] PDF/A accessibility
>>>>>
>>>>> Jon,
>>>>>
>>>>>> Does anyone know if there are any particular accessibility
>>>>>> limitations to PDF/A documents compared with standard PDF
>>>>>> documents
>>>>>
>>>>> There are none... unless you are relying on JavaScript to enhance
>>>>> accessibility in a PDF form, for example. (PDF/A prohibits
>>>>> JavaScript).
>>>>>
>>>>>> , and/or if there are
>>>>>> any special steps that should be taken to ensure PDF/A documents
>>>>>> are accessible?
>>>>>
>>>>> There are no "special" steps other than those steps required to
>>>>> make any PDF accessible (tagging). That said, a good workflow for
>>>>> accessible PDF/A documents would start with ensuring that you can
>>>>> readily convert the PDF to PDF/A before investing significant
>>>>> time/effort
>>>> into tagging.
>>>>>
>>>>>> The specific situation we're facing is converting fairly simple
>>>>>> Word docs (no images, no tables, no multiple columns) to PDF/A,
>>>>>> but any experience anyone has with this would be very helpful.
>>>>>
>>>>>
>>>>> 1) Ensure the files are properly structured prior to conversion
>>>>> (ie, focus on accessibility in the source document)
>>>>>
>>>>> 2) Convert to PDF using software that preserves that structure,
>>>>> converting it into tags in the PDF. Both Adobe Acrobat's "PDFMaker"
>>>>> plugin for Word
>>>>> (Windows) and Microsoft Office itself can do this.
>>>>>
>>>>> 3) Validate the tags, etc. per normal.
>>>>>
>>>>> 4) Convert to PDF/A once the file is otherwise finalized.
>>>>>
>>>>> I hope this helps.
>>>>>
>>>>> Duff Johnson
>>>>>
>>>>> US Committee for ISO/DIS 14289 (PDF/UA), Chair
>>>>>
>>>>> p +1.617.283.4226
>>>>> e <EMAIL REMOVED>
>>>>> t http://www.twitter.com/duffjohnson
>>>>> w http://www.duff-johnson.com
>>>>>
>
>
>
>
>