PDF Accessibility – part 2 of 3 (reading fields)

This blog is the second in a series that explores PDF accessibility. This installment describes how to implement PDFs using Adobe LiveCycle Designer so that form fields are accessible to users of assistive technologies.

In this series:

PDF Accessibility – part 1 of 3 (introduction) – an introduction to accessibility standards and technologies
PDF Accessibility – part 3 of 3 (reading text) – a step-by-step guide on making text accessible

WCAG 2.0 Guidelines

1.1.1	Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose
2.4.6	Headings and Labels: Headings and labels describe topic or purpose
3.2.4	Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently
3.3.2	Labels or Instructions: Labels or instructions are provided when content requires user input
4.1.2	Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies

These guidelines are all about making it easier for assistive technology users to use form fields.

This is important due to the way that assistive technology users interact with a form. Although, fields are typically represented by un-informative shapes such as a rectangle, unimpaired users can rapidly determind its purpose. They have the benefit of being able to scan a form by eye in any direction that they choose and see fields in context;  location, label and surrounding content. Assistive technology users can access the same information, but at a slower pace. Mechanisms are required to enable the user to navigate directly through the fields, ignoring other content, and for alternate text to be read which describes the fields’ purpose without relying on context.

Using the field’s caption for alternate text

Whenever possible you should use the field’s caption for alternate text. Set the ‘Screen Reader Precendence’ property to ‘Caption’ in the accessibility pallet.

When a user tabs into this field, the screen reader JAWS V10 with default configuration reads the following:

Your country of citizenship… edit… type in text

The alternate text is read first to identify the field. This is followed by additional information to help the assistive technology user. In this case, it tells the user what type of field this is and how to use it. Although, this approach is common, the text read is specific to screen reader.

Setting custom text for alternate text

There are occasions when it is not appropriate to use the field’s caption, including:

• The field has no caption
• The caption is too verbose
• The caption is not meaningful out of context

Set the ‘Screen Reader Precendence’ property to ‘Custom Text’ and enter the custom text in the ‘Custom Screen Reader Text’ property in the accessibility pallet.

The field has no caption

It is sometimes necessary to implement a field’s label as a separate text object, for instance to implement multi-line labels:

In this case, it is common to use the text from the label object as custom text.

The caption is too verbose

It is important that the alternate text for a field is concise. Verbose captions that are provided to assist a sighted user may be frustrating for a user of assistive technology.

In this case, it is common to paraphrase the caption text.

The caption is not meaningful out of context

Field captions can depend on context to make sense. A common example is radio button lists. Typically, a separate text object is implemented to ask a question and a radio button is provided for each answer.

For instance, when a user tabs into a yes/no radio button list that uses the caption for alternate text, the screen reader JAWS V10 with default configuration would read the following:

Yes… radio button not checked… one of two

To resolve this, it is common to provide custom text that combines the question with the response for that radio button.

A closer look at how alternate text works

How alternate text is read is dependent on the assistive technology used. You can use the attached AltText-TestForm to test. The two most popular screen readers were used for this article:

• JAWS V10
• Window-Eyes V7.1

Screen Reader Precedence

The ‘Screen Reader Precedence’ property on the accessibility pallet has the following values:

1. Custom Text
2. Tooltip
3. Caption
4. Name
5. None

The screen reader uses this property to determine what text to read. If no text is found, then the screen reader searches for text in the precendence order, starting from Custom Text.

When ‘None’ is selected Window-Eyes performs a search through the precedence order. JAWS does not search through the precedence order, but tries to find a caption, including looking for a text object that may be the label for this field. As a last resort, both screen readers read nothing for the field description, resulting in:

edit… type in text

Using tooltips

Tooltips are used to provide sighted users assistance with completing fields. The text is displayed in a box when the user hovers the cursor over a field.

Typically, tooltips are too verbose to be used as alternate text. To make important tooltip information accessible, it should also be displayed in the form content.

c9eq4xmrbv