Accessibility and Dynamic Forms

I’ve received a number of questions and seen a number of forum postings lately regarding accessibility and dynamic forms created by Designer or rendered through the Forms module.   Dynamic forms ARE accessible, but this is accomplished in a slight different way than static PDF forms and requires a different approach.    

Dynamic forms render directly to the screen because they get updated and redrawn on a regular basis.  This bypasses the regular tagged structure that static forms or other PDF documents produce.  This approach provides better performance for dynamic forms because it avoids generating the whole structure every time the layout of the dynamic form changes. Dynamic forms will work with Jaws because they communicate through the MSAA (MicroSoft Active Accessibility) interface to tell it what text to speak.   The Read Out Loud capability in Acrobat and Reader relies on the structure of the PDF and therefore can not read dynamic forms.   Saving the form as Static PDF from Designer produces the structure that Read Out Loud is expecting.   The accessibility checking function in Acrobat is also expecting the tagged structure and does not check the accessibility of dynamic forms.   Dynamic forms should be accessibility tested with a screen reader such as Jaws for the best result.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.8/10 (6 votes cast)
Accessibility and Dynamic Forms, 8.8 out of 10 based on 6 ratings

About Jeff Stanier

Adobe Systems Canada Inc. Director, AEM Forms & Connect, Digital Marketing Email Phone: 613-940-3677
This entry was posted in Document Services, General Interest. Bookmark the permalink.

4 Responses to Accessibility and Dynamic Forms

  1. Masi says:

    We have tested dynamic forms and it works on most cases. Few problems still occurred.
    – One big problem is when form is opened into browser plug-in. Sometimes the form doesn’t get focus and the screen reader doesn’t read the form content.
    – Second problem is button tooltips (that are read by the screen reader). Some screen readers doesn’t read button texts correctly on all Reader versions.
    – When user enters into date picker. Our test users didn’t realize what the component was or what they supposed to enter.
    – Radio buttons seemed very difficult to use for test users. Screen reader should read all choices or comment that there are x number of choices left.

    And one of the biggest problems was if users didn’t had Reader installed. Installing Reader from Adobe web page was very difficult for users with screen reader and most of the test users couldn’t install Reader without help.

  2. Jeff Stanier says:

    Hi Masi,

    Thanks for the comment. I’ll do a little research and post a reply on what is known about these issues.


  3. Jeff Stanier says:

    Hi Masi,

    I did a bit of checking. Here’s what I have found out:

    There is an issue with respect to initial focus on the PDF form in Firefox, it does not occur in IE. A bug has been logged on this but I don’t have an ETA on a fix yet. It is due to the API used to integrate Reader and FF.

    On the bug tooltip issue the current behavior is that screen texts for buttons is not read by JAWS. Only the caption is read by JAWS. The Reader team plans to make conveying of tooltip text to assistive technology more consistent so that screen readers can speak it if they choose to. It will be up to the vendor of the screen reader to implement it.

    For the date picker. JAWS says “date time edit” to indicate that the user is in a Date Time field. The down arrow will activate the month calendar control. In some cases, like in some screen readers’ forms filling mode, up and down arrow will be consumed by the screen reader, hence Reader will not see those keystrokes. Alt down arrow will activate the month calendar control. This keystroke is provided as an alternative for the case mentioned above where down arrow is consumed by the screen reader.

    I’m still looking into the Radio button issue and will pass along the information about the Reader web page accessibility.

    Hope that helps.

  4. Dave says:

    Hi Jeff,

    Thanks for the post. I was wondering if you could go into a bit more detail about the slight different ways that we need to make dynamic forms accessible. I have just had a form rejected just because the tags were not visible within the Acrobat tag panel. They appear if the form is saved as static but that does not suit the data structures I have to deal with.

    I hope you can help.