Fear and loathing in the Reading Order panel

cp,

My gut feeling is that you might be better off rebuilding the form directly as an Acrobat form or a LiveCycle form.
To get anywhere with post-processing a PDF, with complex content, for tags (before becoming Rip Van Winkle)
the output PDF really needs to have been a fairly well formed tagged output PDF to begin with.

Reflow, read order, accessiblity sort of hinge on a well formed tag structure tree.

Sounds like a lot of layout tables. These just don't fit into the PDF Table tag's hierarchy.

This [url=http://www.acrobatusers.com/forums/aucbb/viewtopic.php?id=15622]thread[/url] has a listing of resources.
Read order and its involvement with other aspects of tagged PDF is tucked away in several.
The PDF Reference is a good starting document.
Adobe staff has placed a number of informative items into the [url=http://www.acrobatusers.com/topics/accessibility]AUC Learning Center[/url].
These may be helpful to you.

Be well...

Thanks, Daka -- unfortunately rebuilding the form isn't an option at this point, and the results I'm getting by recreating the tags are acceptable for our purposes, even if they're not totally optimal.

At some point I'll get a chance to learn how to create docs with a well formed tag structure...but in the meantime I mostly want to figure out how to beat the Reading Order panel into submission and get this monster off my desk.

But thank you so much for the links -- those are extremely helpful!

cp

Hi,

I'm having a similar issue to cwparks regarding the Reading Order panel in Acrobat. A PDF has been generated from Quark 7, and it's my job to make it 508 compliant. It's a 40-page document with lots of text and images.

I'm having trouble with the Acrobat Pro 9 screen reader reading things correctly. For some reason, Acrobat is breaking up the paragraphs of text into singular letters and/or shortened versions of words. I've been unsuccessful in finding a way to "combine" letters of text in Acrobat (even though they are correct in the original document/PDF). Any suggestions??

Also, the screen reader is not recognizing headings for some reason. Any ideas why?

Any help or suggestions would be much appreciated. Thanks!

Deanna

Hi Deanna,
The text breakup & shortened words comment is kinda-sorta general. Could you post an example,
perhaps to Acrobat.com, and park a link here?

Anyway, some observations/comments - (the peanut gallery, maybe nuts, maybe shells )
What does the PDF's content look like when you save as to Text (Accessible) (*.txt)?
That will show you [i]what[/i] Read Aloud is reading as well as provide an alternate presentation (to the Order panel) of the order (sequence) that Read Aloud is following.

Headings: High light one; find it in the Tag panel. What element has been assigned?
PDF has six heading level tags built in. Appropriate heading tag use in the authoring application ought to get
mapped to a PDF heading tag (such is my experience with FrameMaker and MS Word).

The Order panel lets you adjust the order of reading, not how Read Aloud reads.
Read Aloud gives one the gist of what is on the PDF page. Proper read order and a well formed tag structure provides a smoother Read Aloud rendering and, more importantly, provides the "hooks" that AT such as JAWS or braille devices need.

The TORU tool may show a PDF page of content as a single high lighted block with a single read order digit (1).
However, if properly authored, the requisite tag elements are in fact present in the structure tree. A detail look over of
the page in the Tag panel will demonstrate that. It is these tag elements that the "real" screen readers rely on.
The user of such will then be able to direct the application to "tell what it sees", as it were.
While Read Aloud is an extremely useful tool, it is not of the same caliber as a dedicated screen reader (i.e., JAWS, etc.) and does not provide the same granularity of functionality.


Consider also that Read Aloud is "generic" in the sense of what it has in under-the-hood coding for its
interpretation of text. Consequently it may mangle a word that is "okay" to us but is, in fact, some what
specific to our particular discipline and not adequately recognized by Read Aloud's code.

Having a number of figures and/or tables mixed into a page's text flow can be a post-processing challenge
vis-a-vis read order. Can be done but not fun.

Using an authoring application's table feature for layout can cause problems for Read Aloud or AT applications.
Sometimes you can post-process such tables to 1194.22 (g) &/or (h) compliance; most times not.
The only fix is back in the authoring application.

Some character entities are still a challenge in context of Section 508. Various types of hypens, dipthongs,
equations/forumlas and such are, as I understand it, part of this population. As the PDF/UA working group's
efforts begin to bear fruit I suspect we will see some of these addressed in updates to the ISO specification
and in future Adobe addendums to the specification.

Headings
1.1 Some text becomes 1.1Some text
try \sn at the end of the number sequence and before the tab.
something like .\sn
For Read Aloud, this results in a bit of a pause between "1.1" and "Some...";
may not be "ok" with a screen reader(?).

Some "where the rubber hits the road" thumbrules -
Some things are better dealt with back in the authoring files.
Establish a sensible read order.
Use save as text (accessible) to cross-check read order and to see what the authoring application
*really* provided for output text to the PDF. That's what read aloud will parse.
Perform Accessibility Full Check for Adobe PDF and Section 508 Weab-based intranet and internet
information and applications (1194.22). Get comfortable with 1194.22.
Note that the 1194.22 paragraphs are "tied" to W3C® Web Content Accessibility Guidelines 1.0
(WCAG 1.0) so visit there and understand what WCAG 1.0 is.
Don't fixate on Read Aloud. If the read order is good, the structure tree elements "well-formed"
(largely dictated by what's done in the authoring application),
and the PDF passes the the Full Checks above your most likely 'good-to-go'.

If your feeling frisky, run the W3C® Web Content Accessibility Guidelines 1.0 Full Check.

The Full Check for WCAG 2, working draft can be interesting. However, "final" WCAG 2.0 rolled out
December, 2008 and the final differs from the draft.

Getting past "most likely 'good-to-go'"
If one had CommonLook a PDF could be vetted with more rigor.
If one had a screen reader a final validation could be done.
However, the associated cost often precludes their inclusion in the authoring toolkit.

PersevereBe well...

I am having this exact same issue. I am also using 9 Pro and I have found that the source document has a lot to do with the outcome of your PDF. Clearing all the page structure (getting rid of tags) seems to keep Adobe more "stable" but it can still freeze up on you. Does anyone know if this issue has been addressed in X?