Tags or Scripts for Accessible Forms?

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

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
(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

‘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?’

You May Also Like

About the Author: Duff Johnson

Leave a Reply