skip navigation

PDF Document Management Software, Services & Support

Server Desktop Services Support Why Us? About Us

The Latest

SecurSign 5 Now Available! Includes Signature Validation to Detect Tampering.
Lansdowne, PA (July 13, 2011)
Encrypt, digitally sign and verify digital signatures on PDF documents.

Redax 5: Advanced Redaction for PDF Documents
Tuesday, March 22, 2011
The latest Redax adds new patterns, regular expressions and more!

Redax Enterprise Server 3 Ships!
Thursday, January 6, 2011
New Redaction Engine, Powerful New Markup Options and More!

Survey: Server Based PDF Applications
Tuesday, December 7, 2010
The 2010 Survey asked about PDF server application development.

5 PDF Readers Compared
Tuesday, November 30, 2010
Expanding on our previous review, we've included Nitro's Reader and Adobe's new Reader X.

PDF Form Aids Sales Team Collaboration
Friday, November 26, 2010
Take a document, add a dash of JavaScript, a sprinkling of PDF know-how, and serve.

Section 508 Center for PDF now online!
Wednesday, November 17, 2010
A key resource for document authors, content managers and Section 508 coordinators concerned with PDF accessibility.

Tags or Scripts for Accessible Forms?

TalkPDF225x100_noDJ.png

Thursday, April 22, 2004

by Duff Johnson

Bryan is a solitary, but well-armed PDF developer, fighting (and winning) an uphill battle to make Canadian government forms PDF accessible to Canadian standards (WCAG priority 2), which are a lot tougher than the relatively simple (and vague) Section 508 regulations.

Originally appeared in:

Bryan basically feels that there's not a lot about tags that promotes accessibility in PDF forms. Scripts are the only thing that makes sense in a form, Bryan believes, and I think he's right. Scripts offer inherent flexibility and power that static tags can never match.

I asked Bryan to give me his top beefs about accessibility implementation in PDF forms, seen from his side of the border. He let it rip:

"Tagged PDF is fine for text documents, but it utterly fails for interactive forms. Tags are dumb and only provide accessibility. Accessibility is only part of the solution, and by itself, is useless. Accessible forms need to be intelligent if they are to be usable. Usability is just as important as accessibility, and Tags offer almost nothing when it comes to usability. This is something that Adobe has totally failed to understand. Anyone can prove this to themselves by going to the IRS Web site and trying out the accessible PDF forms (Tagged PDF) that Adobe and the IRS are so proud of. They may be accessible, but they are totally unusable. As my blind colleague recently commented 'they are nothing more than talking forms, and they don't even talk that well.' The only way to add genuine usability to a PDF form is with JavaScript. Unfortunately, Tags and JavaScript are often at odds if you follow Adobe's published recommendations. The end result is unruly and confusing and very hard to implement."

"Creating an accessible tagged PDF form is an error-prone and laborious process that is far too costly to implement for government or business alike. It also requires a new skill set, and the use of crude, unproven tools that often cause corruption in forms. That is why I chose to completely ignore Adobe's recommended workflow and developed my system."

"The Adobe Acrobat 3.x, 4.x, and 5.x calculation mechanisms are extremely limited and unreliable. If you must use the built-in calculation mechanism, do so with great caution, and test your calculations for every possibility."

"Calculation is only permitted for number fields! This can be extremely limiting, because enabling the number field-format option has the effect of DISABLING custom keystroke scripts needed for so many other uses, such as enhanced usability features. The only option is to use your own custom formatting and calculation system, and this is not a trivial matter. Even Adobe, with its massive resources, cannot deal with the issue of formatting adequately, so it is unlikely individual forms developers can. Unlikely doesn't mean impossible however. JavaScript is very powerful and with some effort a complete custom formatting and calculation system can be developed."

"If you attach a calculation to a field, that field will automatically display at least one zero when it is empty. In other words, it is impossible to have a blank calculation field. This flies in the face of PDF's overall support of the paper metaphor! The current reality is that most PDF forms are used as fill-and-print, or print-and-fill forms. The first type is where you open the form with your computer, type in your information and then print a completed copy. This is not a problem. However, many people need to print a blank copy of the form so they can fill it out with a pen or typewriter. If there are calculations in a form it becomes impossible to print a blank copy because of those default zeros. The end result is that forms developers must develop one version of the form for print-and-fill, another version for fill and print, and because calculations are so unreliable and limiting, another version for accessibility, and many forms also need yet another version of commercial print. The sad truth is that PDF can do all these things in a single form, but not with the built-in tools and methods Acrobat provides."

"The 'Required Field' option (see the Field Properties Appearance tab) is actually anti-useful. This option does not force the user to fill out a field while the field is active (like most forms packages do), or at any time when the form is being filled out. This option only works when the form is submitted to a web server. Sound good? Nope, it sucks. It becomes possible, for example, for a user to enter data out of order, which can (and usually does) result in invalid results, botched calculations, and other problems that the Required option cannot catch. There are ways around this, but it's an absurd headache to contend with, in addition to everything else!"

"Acrobat has no concept of tables. OK, that's fine if you are just using PDF to talk to a printer, but this is a serious obstacle especially for those developing business forms and anything else that is supposed to have a prayer of functional accessibility. Consider this: You have a PDF table of 10 columns by 20 rows. That's 200 fields! If you need to fill out only the first 5 rows (50 fields), then how do you avoid the remaining 150 blank fields? Just click with your mouse to where you want to go next. However that doesn't help keyboard users? Don't forget, blind users and many disabled people cannot use a mouse. The only option for keyboard users is to tab through the remaining 150 blank fields and hope they won't lose their sanity in the process. Acrobat offers no other mechanism for navigating tables. So the onus is on the developer to come up with a solution. Now the form that should take an hour to build suddenly takes 8 hours because of this toothless table system, and this is on top of all the other time consuming workarounds!"

"Laying out or modifying a table in Acrobat is a painstaking and error-prone task. Adobe has completely failed to meet the challenge of tables, both for developers and users. The existing table tool in Acrobat 5 is really just a copy and paste feature in disguise. It offers little or no real value to the forms developer."

"Bookmarks are truncated by the JAWS screen reader (the most popular screen reader) to what is visible in the bookmark pane. As a result, bookmarks cannot be relied upon for accessibility. This greatly complicates the work of forms and document developers."

"Read Only form fields are not accessible. What can one say?"

Originally posted on planetpdf.com



Server Desktop Services Support Why Us? About Us
AppendPDF
AppendPDF Pro
FDFMerge
FDFMerge Lite
pdfHarmony
Redax Enterprise Server
SecurSign
StampPDF Batch
APCrypt
APJavaScript
APSplit
APGetInfo
pdfAPilot Server 2
Redax
StampPDF plugin
StampPDF DE
AppendPDF DE
APSplit DE
PDF Forms
Designer/XFA Forms
PDF JavaScript
PDF Accessibility
Section 508
Publication Scanning
CD/DVD-ROMs
Custom Development
Software Support Policy
Technical Support
Product Documentation
FAQs
Sample Scripts
PDF Glossary
Contact Support

Talking PDF
Appligent Labs
Customers
Testimonials
Case Studies
Cost Effectiveness
Innovation
PDF Standards
Experience
Mission
History
People
Partners
Contact Us
News & Events
Site Accessibility
Site Index
 
Site Accessibility | Email the WebAdmin
Valid HTML 4.01! Section 508 Compliance logo