Creating an Accessible PDF

The following sections describe how to create an accessible PDF document:

• Introduction

• A Sample Tagged PDF

• Best Practices for Tagging PDFs

To download the PDF used in this topic, click Tagging Features PDF.

Introduction

The concept of a "tagged PDF" is central to OneSpan Sign's accessibility solution, since only tagged PDF elements are included in its WCAG HTML representation. Thus all elements intended for accessible content and signing must be tagged (including Signature Fields and those "automatic fields" whose content is triggered by signing).

A tagged PDF can be created automatically from a text editor like Microsoft Word or Adobe FrameMaker. However, such automatic tagging creates only a basic tagged PDF. Such PDFs must subsequently be inspected and possibly changed to ensure that they meet the standards described in the rest of this chapter (see, e.g., Distrust Automatically Tagged PDFs).

The recommended way to add, modify, delete, or drag tags is by using Adobe Acrobat's Tags tool, located in its Navigation Pane (see here).

Full accessibility compliance requires even more than a suitably tagged PDF. For a complete checklist, click here.

A Sample Tagged PDF

The following figure shows the contents of a sample tagged PDF whose file name is Tagging Features.pdf.

The following figure shows the Tags tab for that PDF.

The structure tags on the preceding tab are organized in a hierarchical tree. The document starts with the root called Tags at the top. Inside the root is a set of tags identified by their type (e.g., Part, H1, H2, P, Table). Each tag may contain other tags or leafs.

A "leaf" can be a Form Field, an image, or some text. In the above tab, each leaf is identified by a box icon.

If you right-click a tag on the Tags tab, the following dialog box appears:

That box's fields are:

• Type — The structure tag's type. You can specify it from the associated drop-down list (e.g., Paragraph, Heading Level 1). The accessibility solution uses this type when it converts the PDF tag to an HTML tag.

• Title (optional) — Name for the tag that appears in the PDF Tags view. This field exists only to help the tagging author identify the tags in that view. This information is not read by screen readers.

• Actual Text (optional) — This is replacement text for text that is represented in a non-standard way, especially regarding typography. For example: (1) a glyph for a ligature (ae, oe,, etc.); (2) a math equation. All PDF elements over which this tag is applied will be replaced by the content of Actual Text (see the example in the preceding figure).

• Alternate Text (optional) — This is human-readable alternate text provided for images and other items that do not translate naturally to text. For example, for the image in our sample PDF, the value of this field could be: This is a rainbow happy face.

  It may not be useful to tag a background picture for the visually impaired. If the image is not tagged, the screen reader will not mention it. Nonetheless, some images are important sources of information, so it is usually a good practice to tell the “listener” what an image represents.

• ID (optional) — An identifier for the structure tag (e.g., figure1). The PDF format requires that all such IDs be unique (though they can remain empty). These IDs are exported to HTML. To comply with the identifier rules for HTML5, these IDs cannot contain spaces. Spaces will be removed before the export to HTML.

  In a PDF document, IDs are derived from two sources: (1) the IDs of structure tags; (2) the names of Form Fields. The PDF format requires that each of these be unique in its own “domain”, though the ID of a structure tag can be the same as the name of a Form Field.

• Language (optional) — The language (ISO 639-1) associated with the tag. The TTS engine will use the value of this property to better pronounce the text contained in the tag.

If you click the Content tab on the preceding dialog box, the following screen appears:

The Content tab enables you to specify additional properties of tags. One of the most useful is this:

• Expansion Text (optional) — The TTS engine can have problems with abbreviations and acronyms. It is often better for the engine to pronounce an entire word instead of its abbreviation (e.g., boulevard instead of blvd., or Doctor instead of Dr.). This field enables the TTS engine to do that (see, for example, the value of the Expansion Text in the preceding figure).

Occasionally, a visually impaired person may find it easier to navigate a document if some parts are spoken in an order different from the document's visual order. The logical structure created by the tagging process makes it easy to reorder tags for that situation. Using Acrobat's Tags tool, one need only drag a given line to its desired new location in the displayed tree. The accessibility process will present spoken PDF information in a temporal order that descends sequentially from the tree's root (on top) to its bottom branch. In the following figure, the line “This line is visually below” in the tag tree appears above “This line is visually on top”. Yet they appear in the reverse order on the PDF. The screen reader will follow the order in the tag tree.

The Reading Order tree root and panel can be used to tag the content with HTML semantic tags (e.g., H, P, Form), and to specify the reading order within a screen reader. To be correctly rendered in accessibility mode within the Signer Experience, all the document's content should appear as tagged when you open the following pane:

Best Practices for Tagging PDFs

The following sections describe various best practices:

• A Longer Page Is Preferable to Multiple Pages

• Customize Instructions for Form Fields

• Distrust Automatically Tagged PDFs

• Give Users Clear Instructions

A Longer Page Is Preferable to Multiple Pages

To avoid needless navigation, it is better to have one long page than multiple pages. If a document is well-structured with meaningful PDF tags, it will be easily navigated by a visually impaired person. And if instructions are clear, having multiple pages is unnecessary.

Customize Instructions for Form Fields

When a page contains Form Fields that must be filled, a disabled person will usually switch their screen reader to form mode. In this mode, a user can type text which will not be interpreted as screen-reader shortcuts. The user will move from one field to the next using the TAB key. Each time the screen reader enters an input field, it will read the text of the <label> associated with that field, along with information about the field (e.g., checkbox — unchecked).

If the page contains free text between two Form Fields, it will not be read by the screen reader. In other words, if a description of what to do with a Form Field is in clear text, it will likely be skipped by the screen reader when it’s in form mode.

The correct way to address this problem is to add the required instruction to the Tooltip field of the Form Field's properties dialog box. OneSpan Sign will extract this information from the PDF document, and will make it available to screen readers.

The following figure illustrates how to add a tooltip to a Form Field:

And this next figure illustrates how the tooltip in the preceding figure appears on the PDF. That tooltip will be spoken by a screen reader:

Distrust Automatically Tagged PDFs

Beware of PDF documents that have been tagged automatically. Unless the source document is extremely well structured, automatic tagging will not create a PDF that can be easily navigated by the visually impaired.

For example, the tag tree below was created after a Microsoft Word document was converted to PDF format with automatic tagging. The document's visual appearance (on the right of the figure) would lead one to expect that text 1 would appear first in the tag tree, followed by text 2 .However, the automatic tagging (on the left of the figure) reversed that order.

Give Users Clear Instructions

It is important to tell users clearly what a page contains, which action is immediately required, and which action has just occurred.

When a page is displayed in a browser, the screen reader starts reading it from the top. At that point, it may be unclear to a visually impaired user why the page is being displayed, or what they have to do.

It is critical that a document contain Heading levels (h1 … h6) because they will be a visually impaired person’s main source of information about how the document is structured, and how to navigate through it. This can be achieved by appropriately tagging the PDF document.

If a field has been added automatically to a document’s currently viewed page, it is good to mention that fact at the top of the page. For example:

1. Add the statement “A text field containing the signing date was added to this document at this location”.

2. Over the words “at this location”, insert a hyperlink that links to the new text field.