Accessibility - LiveCycle Designer and Acrobat Professional

As discussed in LiveCycle Designer Help, the output must be PDF in order to
utilize the built in accessibility features.

Tagged PDF output
In addition to specifying text for screen readers, you must also create a tagged PDF form so that the screen reader can read the text. You do this by generating accessibility tags when saving the form design as a PDF file.
In LiveCycle Designer, the default behavior is to create tagged PDF forms.

For the default behavior to be exhibited, use Save As to a PDF output file.
Confirm that, under Save Options:, Generate Accessibilty Information (Tags) for Acrobat, is checked.

The output PDF will be tagged.

Fonts
Again, in the Save As dialog, under Save Options:, confirm that Embed Fonts is checked.
Of course, if fonts utilized are licensed specifically to the user/computer then these won't pass through. Otherwise the fonts will be present in the output PDF. If characters are used that do not appropriately map to unicode the Full Check will identify this issue.

Language
While a few authoring applications will pass through the language, most do not.
Using Acrobat Professional you manually set the language for LiveCycle Designer
output PDF.
File > Properties > Advanced tab; at bottom, set the language.OCR
A PDF with renderable characters cannot be OCR'd.

*bump*

I have ticked the Generate Accessibility Information (Tags) for Acrobat option and still no tags. I have also ticked the embed fonts option and still it won't recognise them.

When I run the accessibility check in Acrobat Professional it tells me that

* The document is not tagged
* This document contains no fonts.

HELP!

I too have saved my LiveCycle form with the option to create tags. No tags show up in the Palette for Tags. Also, unlike Acrobat Pro, there is no item on the menu to manually create tags.

However if I try to read my form with JAWS 10, put it into form mode with [Enter], and tab thru the document, JAWS does recognize the fields and reads my tool tips.

Is that enough? I am not a regular JAWS user, so I am not sure. All the accessibility documents say that there must be tags.

I am using LiveCycle 8. When I added some auto-fill fields, global fields, and had to save as a dynamic pdf, JAWS did not read any tool tips. However as a static PDF (v.7), JAWS does read tool tips.

BTW, I am finding the documentation for LCD thin and the terms unclear.

Thanks for your help.

I would like to add to this list of frustrated LiveCycle users. I too have had to save my file as a dynamic pdf because it has a coninuation button and automatically numbers pages to accomodate additional pages and also uses global fields. JAWS will read it perfectly saved as a static pdf but not as a dynamic pdf.

I am having the same problem:
* The document is not tagged
* This document contains no fonts.
This is for a dynamic pdf. which I need to add "read out loud to"

*BUMP* *BUMP*

I've just watched the highly entertaining eSeminar on Accessibility and meeting the requirements and obligations of WCAG 2.0.

As ever, when it came to this highly important topic in relation to LiveCycle Designer the speaker scooted past the subject! I've said it before and I will say it again.

This is not good enough.

We are encouraged to use LCD to create dynamic and interactive forms but get nothing when it comes to accessibility. I have followed the instructions in the help and from the forums and it does NOTHING.

No tags are generated even when I tick the 'Generate Accessibility Tags' option in LCD. In Acrobat Professional 8.0 the option to add tags is greyed out and the option to amend the reading order is unavailable.

If these forms are inaccessible they will be spiked and the Adobe LCD solution to our forms will be abandoned in favour of something else.

I would be very grateful if someone could provide a step by step guide to accessibility for LCD.

Adobe LiveCycle ES appears to have a robust capability for providing
accessible interactive forms.
[url=http://www.adobe.com/accessibility/products/livecycle/overview.php]Adobe LiveCycle ES accessibility overview[/url]

As LiveCycle Designer is the stepped down version of LiveCycle ES, I'd
guess the question has to be how do the two compare/contrast?

Some resources:
LiveCycle Designer Voluntary Product Accessibility Template
[url]http://www.adobe.com/accessibility/products/compliance/lc_designer_71_508.php[/url]
LiveCycle ES Voluntary Product Accessibility Template
[url]http://www.adobe.com/accessibility/products/compliance/lc_designer_82_508.php[/url]

At the Accessibility standards compliance page -
[url]http://www.adobe.com/accessibility/products/compliance/[/url]
you can expand the "Select product support center" menu to view the inventory of
related "ES" products.

I'm not a LiveCycle Designer "expert"; however, from my read of the documentation the
primary output of LC Designer is the "dynamic" form (an implementation of XML (XFA) wrapped in PDF).
As such, it is NOT a "PDF" as described/defined in ISO 32000-1 or the PDF References that preceeded the
ISO standard. A consequence is that the structure tree of tags (needed for accessibility) is not applicable/present
(directly) for the non-PDF construct (i.e., the XFA).

A useful summation is at the web site of appligent document solutions.
[url]http://www.appligent.com/xfa[/url]

Greg Pisocky (of Adobe) provides a discussion on processing the LiveCycle Designer form ("dynamic" form)
into an accessible PDF.
Greg's document was put out circa Acrobat 7.0 - Regardless, the overwhelming majority of the information is
Still Applicable.

The document is available as PDF or HTML at
[url]http://www.appligent.com/adobeaccessibility[/url]

The portion that discusses obtaining accessible PDF from a LiveCycle Designer file format
(e.g., the XFA wrapped in PDF) can be viewed (HTML) here:

[url]http://www.appligent.com/adobeaccessibility/AdobeAccessChapter3a8.php[/url]

Setting things up is described. The form design (dynamic) ultimately must be saved to a "static pdf form file".
The dynamic form design has no PDF structure tree. The static pdf form file can have the structure tree.
Conceptually, not much difference from use of an authoring application that supports tagged output PDF.
Once in a "real" PDF, with the generated structure tree, Acrobat Professional may be used to post-process for
accessiblity. Once vetted, this PDF (as opposed to the "XFA-PDF") can be "worked" by an AT application.


Be well...

Thanks for this.

Why is a LCD PDF not a true PDF? If it is generated via XML than surely this has its own structure that can be used for tagging purposes?

The forms I create in LCD are saved as Acrobat 8[Dynamic]XML Form[*.pdf]. I then take them to Acrobat Professional and enable them, saving as Acrobat PDF Files [*.pdf].

Running an accessibility check gives me the error message

"This document contains no fonts. If this document appears to contain text, it may be an image-only PDF file"

Tags are generated for static forms but all I get is

Tags

There is still no option to add tags and reading order does not work. The properties options for the tags are unavailable too.

Hi,

"Why is a LCD PDF not a true PDF?"
It seems to me that this short discussion provides the fundamental answer.
[url]http://www.appligent.com/xfa[/url]

Yes, XML has its own structure. LCD is not using "straight-up" XML.
Rather, Adobe's implementation of it (XFA), which supports integration of a rigorous forms
template with input via XML schema, is used. Packaging the xfa in "PDF" permits access to
and use of the form template in a dynamic manner while using Adobe Reader or an Acrobat product.
The XFA, residing in the PDF wrapper, can be provided input or output from or to an XML application.

Regardless, the "package" is not an "PDF".
What is a "PDF"? That is described in the ISO Standard and in the PDF Reference documents.

That "real" PDF can contain a mark up "language" does not make this language the same as some
other mark up language (i.e., HTML, SGML, or XML).
While mango, papaya, and passion fruit are all "fruit", clearly they are not the same.

re: Fonts
Fonts present in the static pdf file ought to be embedded and of a font type that correctly maps to Unicode.
"This document contains no fonts. If this document appears to contain text, it may be an image-only PDF file"
Typically, this message occurs when the page has an image. How was the associated PDF produced/processed?
Perhaps a PDF was processed such that an image output was produced of the source PDF content?

"I then take them to Acrobat Professional..."
My apology, but, belaboring the obvious - has the dynamic LCD form template been "Save As" to a static PDF form file?

The Adobe documentation I have read re: LCD forms and accessibility consistently state that the LCD dynamic form can
be staged and then saved to a static PDF form which in turn can be post-processed, as needed, to provide
and accessible, static PDF form.
(static => no dynamic i/o with associated XML application, no dynamic form field actions, etc.)Unfortunately, the documentation of "what" and "how-to" is fragmented.
Information provided for LCD that is [b]still valid[/b] for LCD 8 (provided with Acrobat 8)
or LCD 9 (provided with Acrobat 9) is only present in the documentation released circa Acrobat 6.
I have a spread of documentation (PDF files) from Acrobat 5 through Acrobat 9.
In general and with specific focus on accessible PDF "what", "why", and "how-to" I have often
located needed information for working with one Acrobat release tucked away in the documentation
provided with an earlier release. Sometimes the newer documentation discusses something but
with less useful "what why how-to".

A document that may be useful is the Adobe Designer Version 6.0 "Creating Accessible Forms".
As web content location(s) sort of floats with the tides of web design/re-design and sometimes
get washed ashore on a beach somewhere and thus is no longer "on the web" I did a search for the
document.

Just now, it is at:
[url]http://www.adobe.com/enterprise/accessibility/pdfs/adobedesigner6_accessibleforms.pdf[/url]

Be well...
N 12 53
W 70.05

I understand what you are saying but this is not my issue. My cry of 'why is the LCD PDF not a true PDF' was not a question about the nitty gritty details. It was more of a question about why Adobe has produced a product that is incapable of being processed in an accessible way by one of its flagship products.

"The Adobe documentation I have read re: LCD forms and accessibility consistently state that the LCD dynamic form can be staged and then saved to a static PDF form which in turn can be post-processed, as needed, to provide and accessible, static PDF form."

The point is that the forms we are building are dynamic. If I save them as static then the advanced features will not work. The guide you link to says that the default behaviour in Designer is to create tagged PDF forms. No distinction is made between static or dynamic.

I don't want a static form as it sort of undermines the whole point of using LiveCycle Designer to create super whizzy forms with validation, tables and repeating row subforms when they can't be used in an accessible way by one of the main products in the Adobe family.

I don't embed fonts because that dramatically increases the file size.

Even if I do save the form as a static PDF I can't amend the properties of the tags to specify a language or indeed any of the touch up properties.

This whole 'real' versus 'pseudo' PDF thing is nonsense. Even after the nth iteration of Acrobat and Designer they still can't work together? The whole situation is ridiculous.

I'm not talking about 'fruit' I'm talking about two specific products in the same software suite. I don't think it is unreasonable of me to expect that the two products would work together in a way that we had been led to believe by Adobe. When I am given an option to save a file as a PDF I don't think it is unreasonable to assume that the file will be saved as a PDF rather than 'almost but not quite approximation of a PDF'.

This is an old topic and perhaps has been addressed in other discussions. I thought I'd respond here in case someone happens to land here, like someone on our staff did, by googling for PDF accessibility guidance.

We ran into these same issues when we started converting our old WordPerfect macro-based internal forms into dynamic PDFs. We were fortunate enough to have some Adobe engineers onsite for a week. We learned that for Acrobat to recognize an LCD 8 dynamic form as tagged, you must first open any screen reading program such as JAWS. Bizarre but true. If you open your screen reader, then open the form in Adobe and run the full accessibility check, you will no longer see the untagged error.

However, we see some additional errors:
* Graphic elements have no alternative text (but they do!)
* No language specification (we do specify U.S. English in LCD's Locale property, but that doesn't get translated to Adobe's Language property, and you're probably aware that these properties are locked down in Adobe anyway.)

After trial and error we use a combination of Adobe's full accessibility check plus the read out loud feature to test our forms. It's a hassle but we deal. The read out loud feature verifies for us tab sequence and alternative text for graphics.

Saw this in the LiveCycle ES U1 SP3 installation instructions on page 22:
http://download.adobe.com/pub/adobe/magic/livecycle/designer82/LC_8.2.1_SP3_Localized_Readme.pdf
Documentation Issues
● The documentation needs to mention that no tags are saved for forms with a flowable layout even
when the Save option in the form properties is set to “Generate Accessibility Information (Tags) for
Acrobat (default)”.

This document may be of interest as well, [url=http://www.adobe.com/accessibility/products/livecycle/pdf/LiveCycle8_2AccessibilityGuidelines.pdf]Best Practices for Accessible Forms in Adobe LiveCycle Designer ES[/url].

Thank you for this!

I'm trying to figure out if forms with a flowable layout can be made accessible, and I came across this gem in LCD ES Help:

It sounds like this is what you're talking about. Unfortunately, I'm in an environment where the only screen reader I have is Acrobat's Read Out Loud feature...I just can't quite wrap my head around how to "open the screen reader" before I open the form in Acrobat. Am I missing something?

I create forms in Acrobat (9.0 Pro) instead of LCD because in general I'm mandated to deliver a clean accessibility report with each document, so I've never learned LCD. However, the forms that need a flowable layout may simply need to be *functionally* accessible, without requiring the accessibility report. If the LCD form is actually accessible even though I can't get a clean report, it may be worth taking the time to learn it...but I'm skeptical.

For the record, R_Boyd, I'm with you. Adobe is seriously missing at least the spirit of Section 508 by not seamlessly giving users of assistive technology the same options and experience as non-users.

Hi cwparks,

Acrobat's Read Out Load is not an "assistive technology screen reader".
If you need to perform a check of your output PDF using AT you'll be wanting an AT application.
Some examples would be:

JAWS
Windows-Eyes
NVDA

Be well...

The real problem seems to be that nothing can be modified (using Acrobat) in the final PDF, as LCD forms cannot be edited in Acrobat. So language assignments, or any other "tweeks" to tags or other accessibility issues, cannot be made in Acrobat. Or am I missing something?