E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Chagnon | PubCom
Date: Mon, Jul 08 2013 12:25AM
Subject: Accessible PDF Forms
No previous message | Next message →

Is there any good information or guidelines on creating accessible PDF
forms? Not regular web forms, but PDF forms.

Looking for information appropriate for complex government forms, especially
about structure and tags such as when form fields are embedded within
narrative text.

Thanks,

Bevi Chagnon

- PubCom.com - Trainers, Consultants, Designers, and Developers.

- Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.

From: Olaf Drümmer
Date: Mon, Jul 08 2013 1:23AM
Subject: Re: Accessible PDF Forms
← Previous message | Next message →

Hi Bevi,

quick question before diving into any details - which of the following would you have in mind:

[1] complex layout but all fields are static (always visible, stay where they are) and non-interactive (no JavaScript involved, e.g. no dialogs popping up, no validation of input, etc. - i.e. a behaviour pretty much like a paper based form)

[2] complex layout but all fields are static (always visible, stay where they are) but there is interactive per field logic, like validating input (can it really be a ZIP code) or providing instructions through an alert with a specific explanation when a field is left empty (though already for forms according to item [1] it can be expressed that a field is required), or maybe a submit button that sends the filled out form to some server

[3] complex layout but some fields - or even groups of fields - are dynamic - they only become visible when needed ("how many hours per week do you work?" only shows when person has checked "I am an employee."); or form fields are added as needed (you have earned so much money that usual number of fields of income sources in your tax form is not sufficient, so more fields are shown as you go), whole pages are inserted depending on user input, etc. In addition the form might be interactive or not in a number of ways.

Item [3] can usually only be done using a special technology by Adobe, called XFA (for extensible forms architecture) which ultimately is XML encoded form logic and data deployed inside a minimal PDF container (some would say XFA actually is not PDF - it just happens to work inside a PDF hull when opened in Adobe Reader or Adobe Acrobat). The plain PDF technology typically used in items [1] and [2] is referred to as AcroForms (at least by techie people) - ironically despite the Acro in this name it is the non-proprietary PDF form technology, part of the official ISO standard for PDF (XFA, while publicly documented, is owned and controlled by Adobe, though other vendors are free to implement are as well, and some are working on XFA support, though all implementations I am aware of are partial XFA implementations).

Depending on which of the above you are about to create, different aspects will apply.


Olaf


On 8 Jul 2013, at 08:25, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> Is there any good information or guidelines on creating accessible PDF
> forms? Not regular web forms, but PDF forms.
>
> Looking for information appropriate for complex government forms, especially
> about structure and tags such as when form fields are embedded within
> narrative text.
>
> Thanks,
>
> Bevi Chagnon
>
> - PubCom.com - Trainers, Consultants, Designers, and Developers.
>
> - Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
> Accessibility.
>
> > >

From: Chagnon | PubCom
Date: Mon, Jul 08 2013 9:30AM
Subject: Re: Accessible PDF Forms
← Previous message | Next message →

Olaf, thanks for such a clear and concise categorization of PDF forms!
Options 1 and 2 are what I need to focus on.
This is for a variety of forms from different government agencies. For the
most part they are static paper-like forms, and they can have any of the
following:

1. All of the regular PDF form fields, including drop-down lists, radio
buttons, and check boxes.
2. Buttons to reset, print, submit, and save the PDF.
3. Fields that automatically calculate a sum.
4. The PDF digital signature field.
5. Only minimal validation of field data (numbers, decimal places, date
formats, zip codes, phone numbers) but not testing whether it's a working
email address or correct ZIP code.

I've leaving out JavaScript, XFA, and other technologies for another day.
<grin>

Also looking for guidelines on the design of government forms, such as:

5. Where visible field labels should appear, before, after, above, left,
right of the field.

6. Hierarchy of nested fields. Example:
(parent field checkbox) Yes, I am a student.
(child field checkbox) Full-time.
(child field checkbox) Part-time.

7. How to reduce redundant information voiced by screen readers. Example: 3
radio button choices for type of business.
The visible label for the radio button group reads "Select one
federal tax type."
3 button choices follow, each with its visible label, "Corporation,"
"Sole Proprietorship," "Individual."
The guidance I've found so far recommends that the information in
visible labels should be repeated in the form fields' tooltip settings, so
in this example, "Select one federal tax type" would be repeated for all 3
radio buttons.

This produces the following effect:
If reading the PDF from top to bottom (not tabbing from field to field),
it's voiced: Select one federal tax type. Select one federal tax type.
Corporation. Select one federal tax type. Sole Proprietorship. Select one
federal tax type. Individual.
If tabbing from field to field, the visible labels (and visible
instructions) are skipped, only the tool tips and value choices are voiced:
Select one federal tax type. Corporation. Select one federal tax type. Sole
Proprietorship. Select one federal tax type. Individual.

Long list, and I apologize.

—Bevi
— PubCom.com — Trainers, Consultants, Designers, and Developers.
— Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
— It's our 32nd year!

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Olaf Drümmer
Sent: Monday, July 08, 2013 3:23 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible PDF Forms

Hi Bevi,

quick question before diving into any details - which of the following would
you have in mind:

[1] complex layout but all fields are static (always visible, stay where
they are) and non-interactive (no JavaScript involved, e.g. no dialogs
popping up, no validation of input, etc. - i.e. a behaviour pretty much like
a paper based form)

[2] complex layout but all fields are static (always visible, stay where
they are) but there is interactive per field logic, like validating input
(can it really be a ZIP code) or providing instructions through an alert
with a specific explanation when a field is left empty (though already for
forms according to item [1] it can be expressed that a field is required),
or maybe a submit button that sends the filled out form to some server

[3] complex layout but some fields - or even groups of fields - are dynamic
- they only become visible when needed ("how many hours per week do you
work?" only shows when person has checked "I am an employee."); or form
fields are added as needed (you have earned so much money that usual number
of fields of income sources in your tax form is not sufficient, so more
fields are shown as you go), whole pages are inserted depending on user
input, etc. In addition the form might be interactive or not in a number of
ways.

Item [3] can usually only be done using a special technology by Adobe,
called XFA (for extensible forms architecture) which ultimately is XML
encoded form logic and data deployed inside a minimal PDF container (some
would say XFA actually is not PDF - it just happens to work inside a PDF
hull when opened in Adobe Reader or Adobe Acrobat). The plain PDF technology
typically used in items [1] and [2] is referred to as AcroForms (at least by
techie people) - ironically despite the Acro in this name it is the
non-proprietary PDF form technology, part of the official ISO standard for
PDF (XFA, while publicly documented, is owned and controlled by Adobe,
though other vendors are free to implement are as well, and some are
working on XFA support, though all implementations I am aware of are partial
XFA implementations).

Depending on which of the above you are about to create, different aspects
will apply.


Olaf


On 8 Jul 2013, at 08:25, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> Is there any good information or guidelines on creating accessible PDF
> forms? Not regular web forms, but PDF forms.
>
> Looking for information appropriate for complex government forms,
> especially about structure and tags such as when form fields are
> embedded within narrative text.
>
> Thanks,
>
> Bevi Chagnon
>
> - PubCom.com - Trainers, Consultants, Designers, and Developers.
>
> - Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
> Accessibility.
>
> > > list messages to = EMAIL ADDRESS REMOVED =

messages to = EMAIL ADDRESS REMOVED =

From: Olaf Drümmer
Date: Mon, Jul 08 2013 10:57AM
Subject: Re: Accessible PDF Forms - radio buttons or lists?
← Previous message | Next message →

Hi Bevi,

in order to avoid an unnecessarily complex thread, I am spinning off a few sub topics here (and my other replies) with a slightly modified subject line…:

Regarding radio buttons: I find them somehow inconvenient from a forms design point of view (with and without accessibility in mind). A simple cure could be to use a list field instead of a radio button group. This would also reduce some obvious burden on screen reader users.

So instead of having a radio button group labeled "marital status" and five radio buttons in it for unmarried, married, divorced, widowed and don't know, why not have a list with these five entries? Make sure to use a list field as opposed to a drop-down-list, in order to have all options visible at all times for those who wish to visually access them as easily as possible.

Just an idea…


Olaf


On 8 Jul 2013, at 17:30, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> 7. How to reduce redundant information voiced by screen readers. Example: 3
> radio button choices for type of business.
> The visible label for the radio button group reads "Select one
> federal tax type."
> 3 button choices follow, each with its visible label, "Corporation,"
> "Sole Proprietorship," "Individual."
> The guidance I've found so far recommends that the information in
> visible labels should be repeated in the form fields' tooltip settings, so
> in this example, "Select one federal tax type" would be repeated for all 3
> radio buttons.
>
> This produces the following effect:
> If reading the PDF from top to bottom (not tabbing from field to field),
> it's voiced: Select one federal tax type. Select one federal tax type.
> Corporation. Select one federal tax type. Sole Proprietorship. Select one
> federal tax type. Individual.
> If tabbing from field to field, the visible labels (and visible
> instructions) are skipped, only the tool tips and value choices are voiced:
> Select one federal tax type. Corporation. Select one federal tax type. Sole
> Proprietorship. Select one federal tax type. Individual.

From: Olaf Drümmer
Date: Mon, Jul 08 2013 10:57AM
Subject: Re: Accessible PDF Forms - field labels
← Previous message | Next message →

Hi Bevi,

regarding field labels I tend to recommend the following:

- for each form field and group of form fields there must be a clear visible label
- I prefer them to be before the fillable field(s), i.e. to the left of a field (in a left to right writing system, for Arabic and Hebrew it might have to be to the right), or above the field(s)

- in some cases fields need to be explained; it is common practice - especially in paper based forms - to put such information below the field to be filled, or on a separate page or even a separate document; for my taste, any such explanation should be positioned before the field(s) to be filled, unless it is so long that it would destroy the visual structure of the form; in that case it should be provided on a separate page/in an appendix, ideally with forward and backward clickable links, to make jumping around between field and explanation easier (for everyone, not just people with disabilities)

- in addition there should be an internal, human readable name of the field, usually referred to as tool tip or QuickInfo in form creation user interfaces
- the internal name should be as short as possible and as long as necessary; it should focus on identifying the field at hand, and - at least for my taste - should usually not begin to explain the field; if a user encounters the internal name first and is not sure how to fill the field, the user should consult the content around the field.

- it will always be important that the form is organised in a consistent fashion (I will never forget the green forms US immigration let me fill out when entering the USA via the Visa Waiver program in pre-ESTA times - on the front it followed one presentation structure, on the back a different presentation structure; I filled at least a third of those forms out incorrectly on the fifty or so trans-atlantic trips I did in the last decade, putting information in the wrong fields, and finding out at the bottom of the page that I was running out of fillable areas, and had skipped the first fillable area at the top...

- in general I am not a friend of information that is visible only some of the time; I have seen forms where several paragraphs of explanatory text pop up in a tool tip or in a separate dialog box. This more often than not creates rather than solves problems. If some information is important to at least some users, put it on the pages of the document, and make it easy to recognise it / locate it / find it / navigate to it (and back).


Well organised agencies and companies would have guidelines and templates for this… (and ideally not just for the corporate design aspects of forms).


This is just my 2 cents,

Olaf


On 8 Jul 2013, at 17:30, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> 5. Where visible field labels should appear, before, after, above, left,
> right of the field.
>

From: Olaf Drümmer
Date: Mon, Jul 08 2013 10:59AM
Subject: Re: Accessible PDF Forms - 'intelligent' forms, validation, JavaScript
← Previous message | Next message →

Hi Bevi,

just to put you on the right track here:

even if you do not see the JavaScript code when setting up certain validation and calculation aspects for form fields in Acrobat or other PDF form creation tools - JavaScript is used under the hood (and actually embedded in the PDF).

So once you make your forms even a tiny bit 'intelligent', you can't get it done without JavaScript.

Olaf

On 8 Jul 2013, at 17:30, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> 5. Only minimal validation of field data (numbers, decimal places, date
> formats, zip codes, phone numbers) but not testing whether it's a working
> email address or correct ZIP code.
>
> I've leaving out JavaScript, XFA, and other technologies for another day.

From: Chagnon | PubCom
Date: Mon, Jul 08 2013 10:09PM
Subject: Re: Accessible PDF Forms - field labels
← Previous message | No next message

Olaf, thanks for your excellent comments.

There's a lot of information about the technical aspects of creating
accessible forms, but little about the nuances, exceptions, best practices,
and overall design of forms. Olaf's comments fill in that critical gap.

And of course, there's the accessibility of the text portions of forms
that's often overlooked in the material I've reviewed.

Ted Padova (a well-known Acrobat programmer) has a free guide to PDF forms.
The chapter on accessible forms (Chapter 21) is short and touches only the
basics), but the rest of the book is excellent. Download it here:
http://acrobatusers.com/tutorials/making-forms-accessible (250+ page PDF).

It would be wonderful if WebAIM could provide a best practices reference
guide, something beyond talking about the field name and the tool tip
accessible name. Olaf's comment about using a list rather than radio buttons
is an excellent example. Where to put instructions is another issue to
tackle.

—Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Olaf Drümmer
Sent: Monday, July 08, 2013 12:58 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible PDF Forms - field labels

Hi Bevi,

regarding field labels I tend to recommend the following:

- for each form field and group of form fields there must be a clear visible
label
- I prefer them to be before the fillable field(s), i.e. to the left of a
field (in a left to right writing system, for Arabic and Hebrew it might
have to be to the right), or above the field(s)

- in some cases fields need to be explained; it is common practice -
especially in paper based forms - to put such information below the field
to be filled, or on a separate page or even a separate document; for my
taste, any such explanation should be positioned before the field(s) to be
filled, unless it is so long that it would destroy the visual structure of
the form; in that case it should be provided on a separate page/in an
appendix, ideally with forward and backward clickable links, to make jumping
around between field and explanation easier (for everyone, not just people
with disabilities)

- in addition there should be an internal, human readable name of the field,
usually referred to as tool tip or QuickInfo in form creation user
interfaces
- the internal name should be as short as possible and as long as necessary;
it should focus on identifying the field at hand, and - at least for my
taste - should usually not begin to explain the field; if a user encounters
the internal name first and is not sure how to fill the field, the user
should consult the content around the field.

- it will always be important that the form is organised in a consistent
fashion (I will never forget the green forms US immigration let me fill out
when entering the USA via the Visa Waiver program in pre-ESTA times - on the
front it followed one presentation structure, on the back a different
presentation structure; I filled at least a third of those forms out
incorrectly on the fifty or so trans-atlantic trips I did in the last
decade, putting information in the wrong fields, and finding out at the
bottom of the page that I was running out of fillable areas, and had skipped
the first fillable area at the top...

- in general I am not a friend of information that is visible only some of
the time; I have seen forms where several paragraphs of explanatory text pop
up in a tool tip or in a separate dialog box. This more often than not
creates rather than solves problems. If some information is important to at
least some users, put it on the pages of the document, and make it easy to
recognise it / locate it / find it / navigate to it (and back).


Well organised agencies and companies would have guidelines and templates
for this… (and ideally not just for the corporate design aspects of forms).


This is just my 2 cents,

Olaf