A Runtime Accessibility Checker

I continue to be interested in the challenges of developing forms that give a good experience for visually impaired users using screen readers.  Previously we have focussed on checking accessibility properties at design time. However, analysing the form design template doesn’t always fit the user workflow.  There are cases where accessibility properties are populated at runtime by script or by data binding. In this case, these properties are un-populated in the design version and consequently, the design-time accessibility checker will give warnings — yet at runtime the accessibility experience may be just fine.
In addition, we want to make sure that the accessibility experience adapts to changes in dynamic forms. We need to be able to test accessibility in various states — e.g. after subforms are added or removed.

The obvious answer is to perform accessibility checking at runtime — while the form is open in Reader or Acrobat.  Today we’ll look at a solution to that problem.  A mechanism for instrumenting your forms to allow you to analyse the state of accessibility information at runtime.

The Solution

For those of you who want to use the solution without necessarily understanding how it works, follow these steps:

  • Drag this fragment anywhere onto your form.  It will add a hidden subform with no fields (just script)
  • With the form open in Reader/Acrobat, paste the value “AccCheck” into any field on the form
  • From the resulting dialog, select which accessibility checks to run
  • Copy the results from the report dialog for future reference
  • All elements with accessibility issues will be re-drawn with a 2pt red border.  If the element is a field or draw, it will also be shaded light red and the accessibility error text will be assigned to the tooltip.
  • Close your form and go back to Designer to fix any identified issues

Try it out with this sample form. Note that this form dynamically populates some properties.  The Designer-based accessibility checker will report twice the number of errors.

Hopefully the embedded checker is innocuous enough that you could leave it in a production form.   But if not, you should be able to inject it during your testing phase and remove it when you’re ready to deploy your form.

The Deep End

For those who want to know how this works…

The challenge is to add something to your form without introducing an observer effect — i.e. analytics that can run without changes to your form UI and without impacting normal form processing.

The runtime accessibility checker is designed as a form fragment that you can drag onto any form.  The fragment is a single, hidden subform with no fields, no data binding — just script.
We want to trigger the analysis script without requiring the user add a “check accessibility” button to their form.  In this case, I added a propagating change event to the fragment subform.  This script checks the xfa.event.change event property.  If the change text is equal to “AccCheck”, we launch the accessibility checker.
The checker uses JavaScript dialogs to prompt for checks to perform and has a second dialog to display the results.
The JavaScript performing the checks is adapted from the Designer version of the accessibility checker.  The main difference is that it analyses the Form DOM (the runtime) instead of the Template DOM (the design). 

10 Responses to A Runtime Accessibility Checker

  1. Bill Griffiths says:

    This seems very interesting, but I haven’t been able to get it to work using the instructions given above. Do any special settings need to be enabled?

  2. John Brinkman says:

    Bill:
    The trick is to paste the phrase: “AccCheck” into a field on the provided sample form: Type “AccCheck”, select it, copy/cut it, then paste it. Then you should see the dialog appear.

    John

  3. Robert Baker says:

    The checker currently returns a warning if reader preference is set to “Caption” and the Tool Tip and Custom Screen Reader Text are blank.
    If the screen reader preference is set to “Caption” is a Tool Tip or Custom Screen Reader Text required?

  4. Robert:
    This accessibility checker has no knowledge of any of the screen reader preferences.
    But to your question — my understanding is that for screen readers you need to supply only one of caption or tooltip or assist text. I suppose an enhancement to the checker would be to see that at least one of these have been defined. But for now it checks each property individually.
    John

  5. Karl Nowak says:

    nice work
    just a question
    is there anyway to make this work with designer 8.2

    • John Brinkman says:

      Karl:

      To design a form that uses this capability as-is, you need a designer that can target 9.1 forms (because I’m using a propagating event).
      If you have an older designer, you should still be able to use the script, but you’ll need to trigger it differently. You could put the change event on one specific field in your form and use that field to trigger the checker.
      Good luck.
      John

  6. Rani says:

    Accesibilty issues with the dynamic xml pdf, reads ‘blank’ with screen readers.

    When I save the form as “static”, it works fine with the screen reader. But the form does have some dynamic elements, so when I save it as “dynamic” the screen reader (Adobe’s built-in “Read Out Loud” function), keeps saying:

    “Warning: Empty Page” and no matter where I click on the page it says “Blank”.

    Please explain!

  7. John Brinkman says:

    The Read out Loud feature is different from screen reader functionality. Read out loud is not supported for dynamic forms — but screen reader access is supported.
    John

  8. Dave says:

    Hi John,

    We are just starting accessibility work on our forms as the Australian Disability Discrimination Act now makes disability discrimination unlawful.

    However, the Australian government released a report on PDF accessibility which basically says although Adobe provide the tools to make a PDF accessible the client software (Jaws, Windows-Eyes, etc) are not capable enough to make them compliant and alternative formats must be provided (http://www.finance.gov.au/publications/pdf-accessibility-study/index.html).

    Are you aware of any governments approving PDF documents, or any that have met the WCAG 2.0 standard?

    Also, specifically with a dynamic form generated from Designer I don’t get the a tagged PDF even if I do specify “Generate Accessibility Information (Tags) For Acrobat”, at least they don’t show up in Acrobat. Is this expected behavior, I noticed your sample also doesn’t include any tags. The Designer help says “you must also create a tagged PDF form so that the screen reader can read the text” does this mean dynamic forms are less accessible than static forms?

    Thanks

    Dave

  9. Bruce says:

    Hi Dave (and John)

    I believe with the release of the W3C, PDF Techniques for WCAG 2.0 document, http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/pdf.html, Australian Government agencies can continue using PDF forms as long as all the techniques identified in the document are followed.

    But, John, I also would like to know if “Generate Accessibility Information (Tags) For Acrobat” is meant to work for dynamic forms or am I doing something wrong, when I look in the Tags navigation pane it is always blank.

    Thanks

    Bruce