Tags or Scripts for Accessible Forms?

Duff Johnson Planet PDF Contributing Editor

April 22, 2004

Editor's Note: This article is part of the Accessible PDF Learning Center

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.

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?"