by John Brinkman
One of the great things about PDF forms is that they have a really good accessibility story. You can create PDFs and PDF forms that allow the visually impaired user to interact with the document with the help of a screen reader. However, the quality of the experience is entirely in the hands of the PDF author. If your PDF consists of only a scanned page, the accessibility story is very poor. If your PDF form is richly annotated with audible cues, then the accessibility experience should be very good.
BTW, if you need help, here is a good resource for Accessibility Guidelines.
The problem is that your average form author does not test their result with a screen reader. They may understand the guidelines to make a form accessible, but they do not get feedback as to whether the guidelines have been followed correctly.
How well did your form author do with enabling accessibility? I have written an accessibility checker that will give at least part of that answer. I have written a designer macro (see Designer Macros) that will examine a form and validate the common properties that contribute to accessibility. (I need to repeat the usual caveat – Designer macros are a prototype/kick-the-tires/unsupported feature of Designer ES2).
When you run the macro, this is the dialog the designer user sees:
Some explanation around the various checks:
Fields without captions
A caption is far more valuable in providing context than independent text that may have been placed near the field. With this option the macro will check that all fields have captions except for those that appear in a table cell.
Field with no assist text
There are several sources of data to provide context information for a field: field name, caption, tool tip, and custom (speak) text. "assist text" refers to either a tool tip or custom text. If the field does not have one of these, then the macro reports a warning.
Images with no alternate text
Similar to above, we insist that an image has either a tool tip or custom text. If an image is explicitly marked with "Screen reader precedence: none" then we won’t report a warning.
Tables with no header row
Screen readers have special treatment for tables. Navigating through a table with a screen reader makes sense only if there is a header row providing some guidance. In the absence of a header row we’ll issue this warning.
Read order and tab order diverge
Because of the hierarchical nature of form definitions and the way screen readers traverse them, there are limits on the flexibility of read order. Specifically, it is possible to define a tab order where the order jumps out of a subform and back in again. Read order does not allow exiting a subform before all content has been read. The macro makes sure that the tab order for each subform has only one exit. If there are two exits, then read order will not be able to follow tab order.
Once the script has done its work analyzing the form, it generates a report using the included report template. The report looks like:
Ideally the macro mechanism would have access to the warnings palette, but for the time being, a report will have to be enough.
Here is a Zip file with the files needed for the macro, along with a sample form where I managed to break all the accessibility rules.
I am interested in getting feedback from users if there are other useful checks to make the coverage of the macro more extensive.