WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF Accessibility

for

From: Nancy Johnson
Date: Jul 25, 2011 11:33AM

I am the frontend designer and also do 508 testing. This was a
dynamic form with an XML backend
We used LifeCycle Designer and I went to the accessibility tag section
and added them.

However, it did not work, whenever I used a screenreader, it said it
wasn't tagged.. so I went back into Lifecycle and tried to add them
and again it couldn't be tagged.

I was working with an independent contractor -- working on Adobe
products, although I understood he did some research on the matter.

Later I went to Massachusetts Un-conference in May of 2010 hosted at
Adobe's Waltham MA facility and posed it to someone who was an pdf
engineer not from Adobe... he thought that this kind of dynamic pdf
couldn't be made accessible.... I'm sorry I don't have more specifics
for you.

Thanks Nancy

On Mon, Jul 25, 2011 at 8:34 AM, Andrew Kirkpatrick < <EMAIL REMOVED> > wrote:
> Nancy,
> I'm confused by your message - you're talking about creating dynamic PDF using Flex?  PDf creation is not part of the Flex SDK product, creating Flash-based user interfaces is.
>
> If you use LiveCycle Designer, you can certainly make the forms accessible.  We have best practice information on this at http://www.adobe.com/accessibility/products/livecycle
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>
> <EMAIL REMOVED>
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
> -----Original Message-----
> From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Nancy Johnson
> Sent: Monday, July 25, 2011 8:29 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] PDF Accessibility
>
> A year ago, our team was developing a dynamic pdf form product, I believe using Flex at that time, learned that these forms could not be tagged and made screen reader accessible.
>
> I was using LifeCycle Designer and working with someone from Adobe, even if I tried to tag them correctly using the product, it didn't work.
>
> Is this still correct? or has that changed.
>
> Thanks,
>
> Nancy
>
> On Mon, Jul 25, 2011 at 7:50 AM, McKeithan, Thomas < <EMAIL REMOVED> > wrote:
>> I think that you need to conduct a CBO Analysis to make this determination coupled with determining what's easier for users to gravitate too.
>>
>> Respectfully,
>> Thomas Lee McKeithan II
>> Accessibility Program Manager
>> National Industries for the Blind
>> 1310 Braddock Place
>> Alexandria, VA 22314
>> (703)310-0586 Direct
>> (202)276-6437 Cell
>> <EMAIL REMOVED>
>>
>>
>> "Believing is achieving, for if I believe, I can and I will achieve."
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED>
>> [mailto: <EMAIL REMOVED> ] On Behalf Of
>> <EMAIL REMOVED>
>> Sent: Monday, July 25, 2011 2:51 AM
>> To: <EMAIL REMOVED>
>> Subject: Re: [WebAIM] PDF Accessibility
>>
>>
>> Thanks Bevin for the detailed analysis.
>>
>> I understand that both these tools have more or less the same
>> functionality - CommonLook has an edge when it comes to volume, forms,
>> and tables. But with regards to cost I am not sure if we would greater
>> ROI with CommonLook than Adobe.  With CommonLook - high Cost, less
>> efforts; Adobe - low cost, more efforts. Also, manual testing is
>> required in both tools. So, would Adobe be effective from both
>> solution & cost perspective when we have a set of PDFs with
>> composition 50% Text, 25% Tables, and 25% Forms?
>>
>> Pooja Nahata | Accessibility Practice Lead Content & Design Services @
>> Cognizant Technology Solutions
>> Vnet: 283170 | Hand Phone: +91-9820725102
>> LinkedIn: http://in.linkedin.com/in/poojanahata
>> Twitter: http://twitter.com/Pooja_Nahata
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED>
>> [mailto: <EMAIL REMOVED> ] On Behalf Of Bevi
>> Chagnon
>> | PubCom
>> Sent: Friday, July 22, 2011 6:50 PM
>> To: 'WebAIM Discussion List'
>> Subject: Re: [WebAIM] PDF Accessibility
>>
>> From my experience, I say "it depends."
>>
>> The best workflow is to create an accessible source document (such as
>> MS Word), which in turn produces a very decent PDF that requires the
>> least amount of tweaking in Acrobat PRO X or CommonLook. In this
>> scenario, you don't even need CommonLook.
>>
>> But if you're at the end of the production line and have to fix
>> someone else's lousy PDFs, then CommonLook can come in handy,
>> especially for tables and forms.
>>
>> Both Acrobat and CommonLook can automate things, but the end result is
>> iffy at best:
>>
>> 1) If it's an untagged PDF and tags are automatically added, how well
>> can any software - Acrobat or CommonLook - apply an appropriate tag to
>> items such as headings? These programs will apply tags to the items
>> which partly meets accessibility requirements, but if they're not the
>> right tags you've missed the point of accessibility.
>> Therefore, this feature in both programs doesn't give you everything
>> you need. A human being will still need to review and adjust the tags
>> that are created.
>>
>> 2) It's the same with adding Alt-Text attributes. A human being must
>> look at the graphic and determine whether it's critical information or
>> decorative frou-frou and write the appropriate Alt-Text content.
>> Rarely can this process can not be automated.
>>
>> My recommendation.
>> CommonLook is worth the cost if you have:
>> 1) Lots of PDFs to remediate and you can't go back to the source
>> documents and fix the problems there,
>> 2) Lots of PDF forms to make accessible, and
>> 3) Lots of PDF tables to make accessible.
>>
>> I hope others will chime in with their experiences with CommonLook.
>>
>> - Bevi Chagnon
>>