PDF Techniques for WCAG 2.0

The objective of this technique is to provide text alternatives for images via an /Alt entry in the property list for a Tag. This is normally accomplished using a tool for authoring PDF.

PDF documents may be enhanced by providing alternative descriptions for images, formulas, and other items that do not translate naturally into text. In fact, such text alternatives are required for accessibility: alternate descriptions are human-readable text that can be vocalized by text-to-speech technology for the benefit of users with vision disabilities.

When an image contains words that are important to understanding the content, the text alternative should include those words. This will allow the alternative to accurately represent the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image.

Resources are for information purposes only, no endorsement implied.

• Section 14.9.4 (Replacement Text) in PDF 1.7 (ISO 32000-1)

• Acrobat and Accessibility

• PDF Reference 1.6, 10.8.2 Alternate Descriptions

• PDF and Accessibility

• G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content

Procedure

1. Verify the images which need equivalents have /Alt entries on an enclosing tag by one of the following:

   • Read the PDF document with a screen reader, listening to hear that the equivalent text is read when tabbing to the non-text object (if it is tabbable) or hearing the alternative text read when reading the content line-by-line.

   • Using a PDF editor, check that a text alternative is displayed for each image.

   • Use a tool which is capable of showing the /Alt entry value, such as aDesigner, to open the PDF document and view the GUI summary to read the text alternatives for images.

   • Use a tool that exposes the document through the accessibility API and verify that images have required text equivalents.

Expected Results

• Check 1 is true for each image in the document which needs a text equivalent.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The intent of this technique is to make it possible for users to locate content using bookmarks (outline entries in an Outline dictionary) in long documents.

A person with cognitive disabilities may prefer a hierarchical outline that provides an overview of the document rather than reading and traversing through many pages. This is also a conventional means of navigating a document that benefits all users.

Resources are for information purposes only, no endorsement implied.

• Section 12.3.3 (Document Outline) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• G64: Providing a Table of Contents

Procedure

1. Check that the Bookmarks panel displays bookmarks.

2. Check that the bookmarks link to the correct sections in the document.

Expected Results

• Check #1 and Check #2 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The intent of this technique is to ensure that users can navigate through content in a logical order that is consistent with the meaning of the content. Correct tab and reading order is typically accomplished using a tool for authoring PDF.

For sighted users, the logical order of PDF content is also the visual order on the screen. For keyboard and assistive technology users, the tab order through content, including interactive elements (form fields and links), determines the order in which these users can navigate the content. The tab order must reflect the logical order of the document.

Logical structure is created when a document is saved as tagged PDF. The reading order of a PDF document is determined primarily by the tag order of document elements, including interactive elements, but the order of content within individual tags is determined by the PDF document’s content tree structure.

If the reading order is not correct, keyboard and assistive technology users may not be able to understand the content. For example, some documents use multiple columns, and the reading order is clear visually to sighted users as flowing from the top to the bottom of the first column, then to the top of the next column. But if the document is not properly tagged, a screen reader may read the document from top to bottom, across both columns, interpreting them as one column.

The simplest way to ensure correct reading order is to structure the document correctly in the authoring tool used to create the document, before conversion to tagged PDF. Note, however, that pages with complex layouts with graphics, tables, footnotes, side-bars, form fields, and other elements may not convert to tagged PDF in the correct reading order. These inconsistencies must then be corrected with repair tools such as Acrobat Pro.

When a PDF document containing form fields has a correct reading order, all form fields are contained in the tab order in the appropriate order, and in the correct order relative to other content in the PDF. Common tab-order errors include:

• Form fields missing from the tagged content.

• Form fields in the wrong location in the PDF content; e.g., at the end of non-interactive content.

Resources are for information purposes only, no endorsement implied.

• Section 14.8 (Tagged PDF) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• Making PDF documents accessible with Adobe Acrobat Pro

• G57: Ordering the content in a meaningful sequence
• G59: Placing the interactive elements in an order that follows sequences and relationships within the content
• G202: Ensuring keyboard control for all functionality

Procedure

1. Verify that the content is in the correct reading order by one of the following:

   • Read the PDF document with a screen reader or a tool that reads aloud, listening to hear that each element is read in the correct order.

   • Use a tool that exposes the document through the accessibility API, and verify that the reading order is correct.

2. Verify that the tab order is correct for focusable content by one of the following:

   • Use the tab key to traverse the focus order in the document.

   • Use a tool that is capable of showing the page object entry that specifies the tab order setting to open the PDF document and view the setting.

Expected Results

• #1 and Check #2 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The purpose of this technique is to show how purely decorative images in PDF documents can be marked so that they can be ignored by Assistive Technology by using the /Artifact tag. This is typically accomplished by using a tool for authoring PDF.

In PDF, artifacts are generally graphics objects or other markings that are not part of the authored content. Examples of artifacts include page header or footer information, lines or other graphics separating sections of the page, or decorative images.

Resources are for information purposes only, no endorsement implied.

• Section 14.8.2.2 (Real Content and Artifacts) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

Procedure

1. For an image that is purely decorative, use one of the following to verify that it is marked as an artifact:

   • Read the PDF document with a screen reader, listening to hear that the decorative image is not announced when reading the content line-by-line.

   • Using a PDF editor, make sure the decorative image is marked as an artifact.

   • Reflow the document and make sure the decorative image does not appear on the page.

   • Use a tool that is capable of showing the /Artifact entry or property list, such as aDesigner, to open the PDF document and verify that decorative images are marked as artifacts.

   • Use a tool that exposes the document through the accessibility API and verify that the decorative image is not exposed through the API.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to notify the user when a field that must be completed has not been completed in a PDF form. Required fields are implemented using the /Ff entry in the form field's dictionary (see Table 220 in Section 12.7 (Interactive Forms) of PDF 1.7 (ISO 32000-1). This is normally accomplished using a tool for authoring PDF.

If errors are found, an alert dialog describes the nature of the error in text. This may be accomplished through scripting created by the author (see, for example, SCR18: Providing client-side validation and alert). User agents, such as Adobe Acrobat Pro and LiveCycle, can provide automatic alerts (as described in the examples below).

Note: once the user dismisses the alert dialog, it may be helpful if the script positions the keyboard focus on the field where the error occurred, although some users may expect the focus to remain on the last control focused prior to the alert appearing. Authors should exercise care to ensure that any movement of the focus will be expected. For example, if the alert announces a missing required phone number, positioning the focus on the phone number field when the alert is dismissed can be regarded as helpful and expected. In some cases, however, this may not be possible. If multiple input errors occur on the page, another approach must be taken to error reporting. (See, for example, the Adobe scripting resources.)

Ensuring that users are aware an error has occurred, can determine what is wrong, and can correct it are keys to software usability and accessibility. Meeting this objective helps ensure that all users can complete transactions with ease and confidence.

Resources are for information purposes only, no endorsement implied.

• Section 12.7 (Interactive Forms) in PDF 1.7 (ISO 32000-1)

• Adobe XML Forms Architecture (XFA)

• PDF and Accessibility

• G83: Providing text descriptions to identify required fields that were not completed
• H90: Indicating required form controls using label or legend
• SCR18: Providing client-side validation and alert
• PDF23: Providing interactive form controls in PDF documents
• PDF10: Providing labels for interactive form controls in PDF documents
• PDF22: Indicating when user input falls outside the required format or values in PDF forms

Procedure

For each form field that is required, verify that validation information and instructions are provided by applying the following:

1. Check that the required status is indicated in the form control's label.

2. Leave the field blank and submit the form. Check that an alert describing the error is provided.

3. Use a tool that exposes the document through the accessibility API, and verify that the required property is indicated.

Expected Results

• #1, #2, and #3 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The purpose of this technique is to show how tables in PDF documents can be marked up so that they are recognized by assistive technology. This is typically accomplished by using a tool for authoring PDF.

Tabular information must be presented in a way that preserves relationships within the information even when users cannot see the table or the presentation format is changed. Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal). These relationships are represented in columns and rows, and the columns and rows must be recognizable in order for the logical relationships to be perceived.

Tagged tables can be created using the Add Tags to Document feature in Adobe Acrobat, using the Object Library in Adobe LiveCycle, or converting tables to PDF from a third-party application, such as Microsoft Word. However, the resulting tables may not be tagged correctly and you should ensure that table tagging issues are resolved.

Within PDF documents, a table uses the following structure types for table elements:

• A table element (Table).

• One or more table row elements(TR) which define each row of table cells as immediate children of the Table element.

• One or more table header elements (TH) or table data elements (TD) as the immediate children of each table row element.

• Cells that span two or more rows or columns should use the RowSpan or ColSpan attribute.

• For tables that contain blank cells, you may need to add empty TD cells so that each row or column has the same number of cells.

Resources are for information purposes only, no endorsement implied.

• Section 14.8.4.3.4 (Table Elements) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• H51: Using table markup to present tabular information
• PDF20: Using Adobe Acrobat Pro's Table Editor to repair mistagged tables

Procedure

1. For each table, confirm one of the following:

   • Read the PDF document with a screen reader, listening to hear that the tabular information is presented in a way that preserves logical relationships among the table header and data cells.

   • Using a PDF editor, verify that the appropriate TR, TH, and TD tags are in the proper reading order and hierarchy in the table tree.

   • Use a tool which is capable of showing the table elements to open the PDF document, view the table structure, and verify that it contains the appropriate TR, TH, and TD structures.

   • Use a tool that exposes the document through the accessibility API, and verify that the table structure contains the appropriate TR, TH, and TD structures, and that they are in the proper reading order and hierarchy.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The intent of this technique is to ensure that visually rendered text is presented in such a manner that it can be perceived without its visual presentation interfering with its readability.

A document that consists of scanned images of text is inherently inaccessible because the content of the document is images, not searchable text. Assistive technologies cannot read or extract the words; users cannot select, edit, resize, or reflow text nor can they change text and background colors; and authors cannot manipulate the PDF for accessibility.

For these reasons, authors should use actual text rather than images of text, using an authoring tool such as Microsoft Word or Oracle Open Office to author and convert content to PDF.

If authors do not have access to the source file and authoring tool, scanned images of text can be converted to PDF using optical character recognition (OCR). Adobe Acrobat Pro can then be used to create accessible text.

Resources are for information purposes only, no endorsement implied.

• PDF and Accessibility

• G140: Separating information and structure from presentation to enable different presentations

Procedure

1. For each page converted to text using OCR, ensure that the resulting PDF has been converted correctly, using one of the following ways:

   • Read the PDF document with a screen reader or a tool that reads aloud, listening to hear that all text is read correctly and in the correct reading order.

   • Save the document as text and check that the converted text is complete and in the correct reading order.

   • Use a tool that is capable of showing the converted content to open the PDF document and verify that all text was converted and is in the correct reading order.

   • Use a tool that exposes the document through the accessibility API and verify that all text was converted and is in the correct reading order.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to provide an expansion or definition of an abbreviation for the first occurrence of the abbreviation. For example, a reference to an abbreviation, such as "WCAG," should be available as "Web Content Accessibility Guidelines (WCAG)" on its first occurrence in a document.

This is done by setting expansion text using an /E entry for a structure element, and is normally accomplished using a tool for authoring PDF. A Span structure element is typically used to tag the abbreviation, but the /E entry is valid with any structure element.

This technique is applicable for any abbreviation, including acronyms and initialisms. Note that on the first occurrence of the abbreviation, both the abbreviation and the expansion text must be provided. This will aid recognition of later use of the abbreviation.

PDF documents may be enhanced by providing expansions for abbreviations. In fact, such expansions are required for accessibility to ensure understanding by people who have difficulty decoding words; rely on screen magnification (which may obscure context); have limited memory; or who have difficulty using context to aid understanding.

Resources are for information purposes only, no endorsement implied.

• Section 14.9.5 (Expansion of Abbreviations and Acronyms) in PDF 1.7 (ISO 32000-1)

• Microsoft Inspect.exe tool

• PDF and Accessibility

• G102: Providing the expansion or explanation of an abbreviation
• G55: Linking to definitions
• G62: Providing a glossary
• G70: Providing a function to search an online dictionary
• G97: Providing the first use of an abbreviation immediately before or after the expanded form

Procedure

1. Verify that the first occurrence of abbreviations that require expansion text have /E entries on an enclosing tag by one of the following and that both the abbreviation and the expansion text are provided:

   • In Windows, use Microsoft's Inspect.exe tool, or some other tool that allows inspection of the MSAA interface, to locate the text of the abbreviation in the document tree and ensure that the value of the abbreviation is in the expansion text.

   • In a PDF editor, locate the tag for the text that is the abbreviation, and check that an expansion or definition is provided for each abbreviation in the Expansion Text field in the corresponding tag's properties.

   • Read the PDF document with a screen reader, listening to hear that on the first occurrence, the abbreviation and expansion are read when the screen reader reads the content line-by-line.

   • Use a tool that is capable of showing the /E entry value, such as aDesigner to open the PDF document and view the GUI summary to read the text expansions for abbreviations.

   • Use a tool that exposes the document through the accessibility API and verify that the text expansion of the abbreviation is properly implemented.

Expected Results

• Check #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The purpose of this technique is to show how headings in PDF documents can be marked so that they are recognized by assistive technologies. Headings are marked up using the heading elements (H, H1, H2, ... H6) in the structure tree. This is typically accomplished by using a tool for authoring PDF.

Heading markup can be used:

• to indicate start of main content

• to mark up section headings within the main content area

• to demarcate different navigational sections, such as top or main navigation, left or secondary navigation, and footer navigation

• to mark up images (containing text) which have the appearance of headings visually.

Because headings indicate the start of important sections of content, it is possible for assistive technology users to access the list of headings and to jump directly to the appropriate heading and begin reading the content. This ability to "skim" the content through the headings and go directly to content of interest significantly speeds interaction for users who would otherwise access the content slowly.

Resources are for information purposes only, no endorsement implied.

• Section 14.8.4.3.2 (Paragraphlike Elements) in PDF 1.7 (ISO 32000-1)

• PDF Accessibility Documentation:headings

• PDF and Accessibility

• G141: Organizing a page using headings

Procedure

1. For all PDF content that is divided into separate sections, use one of the following to verify that headings are tagged correctly:

   • Read the PDF document with a screen reader, listening to hear that the list of headings is announced correctly.

   • Using a PDF editor, make sure the headings are tagged correctly.

   • Use a tool that is capable of showing the /Headn entries to open the PDF document and verify that headings are tagged correctly.

   • Use a tool that exposes the document through the accessibility API and verify that the headings are tagged correctly.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to ensure that users of assistive technology are able to perceive form control labels and understand how form controls are used.

Form controls allow users to interact with a PDF document by filling in information or indicating choices which can then be submitted for processing. Assistive technology users must be able to recognize and understand the form fields, make selections, and provide input to complete the forms, and submit the form, just as sighted users can. Understandable labels that convey the purpose of each form control are essential to form accessibility.

Form inputs generally have labels and instructions to help users understand what information is required and how to fill in the form. Unless these labels are programmatically associated with the relevant fields, assistive technology might not be able to associate them correctly, and thus users might not understand how to complete the form.

Using Adobe Acrobat Pro with documents with interactive forms, you can make sure that the forms are accessible and usable by making sure that programmatically associated labels that convey the purpose of the fields are provided.

The heuristics used by assistive technology will sometimes use the text label if a programmatically associated label cannot be found. The TU entry (which is the tooltip) of the field dictionary is the programmatically associated label (see Example 3 below and Table 220 in PDF 1.7 (ISO 32000-1)). Therefore, add a tooltip to each field to provide a label that assistive technology can interpret.

Resources are for information purposes only, no endorsement implied.

• PDF 1.7 (ISO 32000-1)

• Adobe XML Forms Architecture (XFA)

• PDF and Accessibility

• G131: Providing descriptive labels
• G162: Positioning labels to maximize predictability of relationships
• PDF23: Providing interactive form controls in PDF documents
• PDF5: Indicating required form controls in PDF forms
• PDF22: Indicating when user input falls outside the required format or values in PDF forms

Procedure

1. For each form control, verify visually that the label is positioned correctly in relation to the control.

2. For each form control, verify that the name is programmatically associated with the control by one of the following:

   • Open the PDF document with a tool that is capable of showing the name associated with the control and verify that the name is associated correctly with the control.

   • Use a tool that exposes the document through the accessibility API, and verify that the name is associated correctly with the control.

Expected Results

• #1 and #2 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The purpose of this technique is to show how link text in PDF documents can be marked up to be recognizable by keyboard and assistive technology users. That is, the link information is programmatically available to user agents so that links are recognizable when presented in a different format. This is typically accomplished by using a tool for authoring PDF.

Links in PDF documents are represented by a Link tag and objects in its sub-tree, consisting of a link object reference (or Link annotation) and one or more text objects. The text object or objects inside the Link tag are used by assistive technologies to provide a name for the link.

The simplest way to provide links that comply with the WCAG success criteria is to create them when authoring the document, before conversion to PDF.

However, in some cases, it may not be possible to create the links using the original authoring tool. In these cases, Adobe Acrobat Pro can be used to create the link. But, because the tooltip created using the Link dialog in Adobe Acrobat Pro is not accessible to screen readers, be sure that the link text or the link context makes the purpose clear.

In all cases, link purpose should be made clear as described in the general techniques:

• G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence

• G91: Providing link text that describes the purpose of a link

Resources are for information purposes only, no endorsement implied.

• Section 14.8.4.4.2 (Link Elements) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence
• G91: Providing link text that describes the purpose of a link
• PDF13: Providing replacement text using the /Alt entry for links in PDF documents

Procedure

For each hyperlink, verify that the link is correctly tagged and the link text is properly exposed:

1. Read the PDF document with a screen reader, listening to hear that the link is read correctly and that it describes the purpose of the link (i.e., its destination).

2. Visually scan the tag tree to verify that the link is tagged correctly and the link text is exposed (for screen magnifier users and sighted users with cognitive disabilities).

3. Use a tool that is capable of showing the /Link entry value to open the PDF document and view the hyperlink and link text.

4. Use a tool that exposes the document through the accessibility API and verify that the link has the correct link text.

5. Tab to each link and check that it can be followed to its target by pressing Enter.

Expected Results

• #1 or #2 or #3 or #4 is true.

• #5 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to ensure that assistive technologies can gather information about and interact with form controls in PDF content.

The types of PDF form controls are: text input field, check box, radio button, combo box, list box, and button.

Providing name, role, state, and value information for all form components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software used by people with disabilities.

The PDF specification defines how name, role, and value are set for form controls in Section 12.7.4 (Field Types) of PDF 1.7 (ISO 32000-1), as shown in the following table. The Comments column explains how Adobe Acrobat Pro displays the corresponding information.

The following table describes how the role, name, value, and state are defined for PDF form controls created using Adobe Acrobat Pro. Adobe LiveCycle Designer provides the same controls as well as several additional ones: see Example 2 below.

Resources are for information purposes only, no endorsement implied.

• Section 12.7.4 (Field Types) of PDF 1.7 (ISO 32000-1)

• Adobe XML Forms Architecture (XFA)

• PDF and Accessibility

• PDF23: Providing interactive form controls in PDF documents
• PDF5: Indicating required form controls in PDF forms
• PDF22: Indicating when user input falls outside the required format or values in PDF forms

Procedure

1. For the form control, verify that name, role, and value/state are specified by one of the following:

   • Use a screen reader to navigate to the form control and check that it can be activated or that its value can be changed. Verify that the name (tooltip) and role are announced.

   • Use a tool capable of showing the form field information to open the PDF document and verify that the form control has the correct name, role, value, and state (if appropriate) information.

   • Use a tool that exposes the document through the accessibility API, and verify that the form control has the correct name, role, value, and state (if appropriate) information.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to provide replacement link text via the /Alt entry in the property list for a tag. This is usually not necessary, but in some situations, additional information beyond the visible link text is needed, particularly for screen reader users. Screen readers can read visible link text, but replacing the screen text with meaningful alternate text for links in a PDF document can make links more accessible.

Links in PDF documents are represented by a Link tag and objects in its sub-tree, consisting of a link object reference (or Link annotation) and one or more text objects. The text object or objects inside the Link tag are used by assistive technologies to provide a name for the link.

Authors can replace the default link text by providing an /Alt entry for the Link tag. When the Link tag has an /Alt entry, screen readers ignore the value of any visible text objects in the Link tag and use the /Alt entry value for the link text.

The simplest way to provide context-independent link text that complies with the WCAG 2.0 success criteria is to create them when authoring the document, before conversion to PDF. In some cases, it may not be possible to create the links using the original authoring tool. When editing PDF documents with Adobe Acrobat Pro, the best way to create accessible links is to use the Create Link command.

Authors should make sure that the alternate text makes sense in context of the screen text before and after the link.

Resources are for information purposes only, no endorsement implied.

• Section 14.9.4 (Replacement Text) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence
• G91: Providing link text that describes the purpose of a link
• G149: Using user interface components that are highlighted by the user agent when they receive focus
• PDF11: Providing links and link text using the Link annotation and the /Link structure element in PDF documents

Procedure

1. For the hyperlink, verify that the alternate link text is properly coded by one of the following:

   • Read the PDF document with a screen reader, listening to hear that the alternate link text is read correctly.

   • Use a tool that is capable of showing the /Alt entry to open the PDF document and view the hyperlink and alternate link text.

   • Use a tool that exposes the document through the accessibility API and verify that the alternate link text is the text for the link.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to help users locate themselves in a document by providing running headers and footers via pagination artifacts. This is normally accomplished using a tool for authoring PDF.

Running headers and footers help make content easier to use and understandable by providing repeated information in a consistent and predictable way. The content of headers and footers will vary widely depending on the document scope and content, the audience, and design decisions. Some examples of location information that may be used in headers and footers are listed below. Whether the information appears in a header or a footer is often a design decision; page numbers often appear in footers but they may alternatively appear in headers.

• Document title

• Current chapter and/or section in the document

• Page numbers with location information such as, "Page 3-4" or "Page 9 of 15."

• Author and/or date information.

Consistency helps users with cognitive limitations, screen-reader users and low-vision magnifier users, and users with intellectual disabilities understand content more readily.

The easiest way to provide page headers and footers is in the authoring tool for the document. Authoring tools typically provide features for creating header and footer text and information (such as page numbers). However, if after converting your document to PDF, you need to add or modify page headers and footers, authoring or repair tools like Adobe Acrobat Pro's Header & Footer tools can be used. In all cases, the tools generate page headers and footers in consistent and predictable layout, format, and text.

Resources are for information purposes only, no endorsement implied.

• Section 14.8.2.2 (Real Content and Artifacts) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• G61: Presenting repeated components in the same relative order each time they appear
• PDF9: Providing headings by marking content with heading tags in PDF documents
• PDF2: Creating bookmarks in PDF documents

Procedure

1. Check that running headers and/or footers are provided and contain information to help users locate themselves within the document (such as page numbers or chapter numbers).

2. If section headers are used in the running header or footer, check that the section header and the running header or footer are consistent.

Expected Results

• #1 and #2 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to provide a mechanism that allows users to explicitly request a change of context using the submit-form action in a PDF form. The intended use of a submit button is to generate an HTTP request that submits data entered in a form, so it is an appropriate control to use for causing a change of context. In PDF documents, submit buttons are normally implemented using a tool for authoring PDF.

Examples 1 and 2 demonstrate how to add a submit button using specific authoring tools. There are other PDF tools that perform similar functions. Check the functionality provided by PDF Authoring Tools that Provide Accessibility Support.

Resources are for information purposes only, no endorsement implied.

• Section 12.7.5.2 (Submit-Form Action) in PDF 1.7 (ISO 32000-1)

• Create submission forms in LiveCycle Designer

• XML Forms Architecture (XFA) Specification Version 2.5

• PDF and Accessibility

• G80: Providing a submit button to initiate a change of context
• PDF23: Providing interactive form controls in PDF documents
• PDF12: Providing name, role, value information for form fields in PDF documents

Procedure

1. For each page that submits a form, visually verify that the form contains a submit button and check one of the following:

   • Tab to the button and check that it submits the form in response to user action to select the button.

   • Open the PDF document with a tool that is capable of showing the submit-form action and check that the button action is to submit the form.

Expected Results

• #1 is true for each page that contains a form.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to specify a document's default language by setting the /Lang entry in the document catalog. This is normally accomplished using a tool for authoring PDF.

Both assistive technologies and conventional user agents can render text more accurately when the language of the document is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities are better able to understand the content.

Resources are for information purposes only, no endorsement implied.

• Section 14.9.2 (Natural Language Specification) in PDF 1.7 (ISO 32000-1)

• ISO 639-2 Codes

• PDF Reference 1.6, 10.8.1 Natural Language Specification (PDF 8.7 Mb)

• PDF Standards: Natural Language Specification

• Adobe® Acrobat® 9 Pro Accessibility Guide: Creating Accessible PDF from Microsoft® Word

• PDF and Accessibility

• PDF19: Specifying the language for a passage or phrase with the Lang entry in PDF documents

Procedure

1. Verify that the default language for the document is correctly specified by applying one of the following:

   • Read the PDF document with a screen reader, listening to hear that the text is read in the correct natural language.

   • Using a PDF editor, check that the language is set to the default document language.

   • Use a tool which is capable of showing the /Lang entry value in the document catalog to open the PDF document and view the language settings.

   • Use a tool that exposes the document through the accessibility API and verify that the language is set to the default language.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to help users locate themselves in a document by ensuring that the page numbering displayed in the PDF viewer page controls has the same page numbering as the document. For example, Adobe Acrobat Pro and Reader display page numbers in the Page Navigation toolbar. The page number format is specified by the /PageLabels entry in the Document Catalog.

Many documents use specific page number formats within a document. Commonly, front matter is numbered with lowercase Roman numerals. The main content, starting on the page numbered 1, may actually be the fifth or sixth page in the document. Similarly, appendices may begin with page number 1 plus a prefix of the appendix letter (e.g., "A-1").

Authors should make sure that the page numbering of their converted documents is reflected in any page number displays in their user agent. Consistency in presenting the document's page numbers will help make navigating the document more predictable and understandable.

As an example, if /PageLabels has not been provided to describe the page number formatting, the page numbering scheme will not be reflected in the Page Navigation toolbar in Adobe Acrobat Pro or Reader. This toolbar displays the page number in a text box, which users can change to move to another page. In addition, users can select the arrows to move one page up or down in the document. The toolbar also displays the relative page number location. In the image below, the default display indicates the user is on page 1 of 4 pages.

A more direct way of going to a page is to use the shortcut for the View > Page Navigation > Page menu item. On Windows, this shortcut is "Ctrl + Shift + N"; on Mac OS, it is "Cmd + Shift + N". This brings up a dialog box to go to a specific page number.

Resources are for information purposes only, no endorsement implied.

• Section 12.4.2 (Page Labels) PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• PDF14: Providing running headers and footers in PDF documents

Procedure

1. For every section in the document that uses a different pagination format, check that the page navigation feature uses the same format used on the document pages:

   • Select the pages that begin a new pagination format and visually verify that the same format and page number is shown in the page navigation feature.

   • Using a screen reader, check that the page number announced in the page navigation feature is the same as the page number announced on the document page.

   • Using a tool that is capable of showing the /PageLabels entries, open the PDF document and view the entries.

   • Use a tool that exposes the document through the accessibility API, and verify that the /PageLabels entries are specified correctly.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The intent of this technique is to show how a descriptive title for a PDF document can be specified for assistive technology by using the /Title entry in the document information dictionary and by setting the DisplayDocTitle flag to True in a viewer preferences dictionary. This is typically accomplished by using a tool for authoring PDF.

Document titles identify the current location without requiring users to read or interpret page content. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page.

Resources are for information purposes only, no endorsement implied.

• PDF and Accessibility

• Section 14.3.3 (Document Information Dictionary) in PDF 1.7 (ISO 32000-1)

• PDF Reference 1.6, TITLE entry of the document information dictionary

• G88: Providing descriptive titles for Web pages

Procedure

1. Verify that the title for the document is correctly specified and displayed in the user agent title bar by applying one of the following:

   • Open the PDF document with a screen reader, listening to hear that the document title is read correctly.

   • Using a PDF editor, check that the document title is specified. Select the Initial View tab to check that the title will be displayed.

   • Use a tool which is capable of showing the /Title entry value in the document catalog to open the PDF document and view the /Title entry and /DisplayDocTitle flag settings.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to specify the language of a passage, phrase, or word using the /Lang entry to provide information in the PDF document that user agents need to present text and other linguistic content correctly. This is normally accomplished using a tool for authoring PDF.

Both assistive technologies and conventional user agents can render text more accurately when the language is identified. Screen readers can load the correct pronunciation rules. As a result, users with disabilities are better able to understand the content.

Resources are for information purposes only, no endorsement implied.

• Section 14.9.2 (Natural Language Specification) in PDF 1.7 (ISO 32000-1)

• ISO 639-2 Codes

• PDF Reference 1.6, 10.8.1 Natural Language Specification (PDF 8.7 Mb)

• PDF Standards: Natural Language Specification

• Adobe® Acrobat® 9 Pro Accessibility Guide: Creating Accessible PDF from Microsoft® Word

• PDF and Accessibility

• PDF16: Setting the default language using the /Lang entry in the document catalog of a PDF document

Procedure

1. Verify that the language of a passage, phrase, or word that differs from the language of the surrounding text is correctly specified by a /Lang entry on an enclosing tag or container:

   • Read the PDF document with a screen reader that supports the language of the phrase and the language of the surrounding text, listening to hear that the text is read in the correct natural language.

   • Using a PDF editor, select the word or phrase that is in the different language and check that the language is set correctly.

   • Use a tool which is capable of showing the /Lang entry value to open the PDF document and view the language settings.

   • Use a tool that exposes the document through the accessibility API and verify that the language for the passage or phrase is set correctly.

2. Verify that if the container or tag contains the entire document, the language setting is the language intended as the default for the document.

Expected Results

• #1 and #2 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The purpose of this technique is to show how table cells in PDF documents can be marked up so that the logical relationships among rows and columns are preserved and recognized by assistive technology. This is typically accomplished by using a tool for authoring PDF.

However, tables converted to PDF may have incorrectly merged or split table cells, even if they were marked up correctly in the authoring tool. Authors can ensure that table cells are structured properly by using the Table Editor in Adobe Acrobat Pro's TouchUp Reading Order tool.

Resources are for information purposes only, no endorsement implied.

• PDF and Accessibility

• 14.8.4.3.4 (Table Elements) in PDF 1.7 (ISO 32000-1)

• H51: Using table markup to present tabular information
• PDF6: Using table elements for table markup in PDF Documents

Procedure

1. For a table that has been repaired with the Table Editor, confirm one of the following:

   • Read the PDF document with a screen reader, listening to hear that the tabular information is presented in a way that preserves logical relationships among the table header and data cells. (Configure the screen reader to not use heuristics to read table header cells.)

   • Using a PDF editor, verify that the appropriate TR, TH, and TD tags are in the proper reading order and hierarchy in the table tree.

   • Use a tool which is capable of showing the table elements to open the PDF document, view the table structure, and verify that it contains the appropriate TR, TH, and TD structures.

   • Use a tool that exposes the document through the accessibility API, and verify that the table structure contains the appropriate TR, TH, and TD structures, and that they are in the proper reading order and hierarchy.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The intent of this technique is to create lists of related items using list elements appropriate for their purposes. PDF files containing lists are normally created or repaired using a tool for authoring PDF.

When markup is used that visually formats items as a list but does not indicate the list relationship, users may have difficulty navigating the information. An example of such visual formatting is simply using line-breaks to separate list items.

Some assistive technologies allow users to navigate from list to list or item to item. If the lists are not correctly formatted with list tags, these users will have difficulty understanding the list content.

The easiest way to create lists in PDF content is to format them properly using list markup in the authoring tool, for example, Microsoft Word or OpenOffice.org Writer. However, if you do not have access to the source file and authoring tool, you can use Acrobat Pro's TouchUp Reading Order tool and the Tags panel.

The PDF specification defines list structure in section 14.8.4.3.3 (List Elements). The structure types for lists in PDF documents are:

• L - the List tag, which contains one or more LI tags.

• LI - the List Item tag. List item tags can contain Lbl and LBody tags.

• Lbl - the list item label. Contains distinguishing information such as a item number or bullet character.

• LBody - the list item body. Contains list item content, or in the case of a nested list, it may contain additional List tag trees.

Resources are for information purposes only, no endorsement implied.

• Section 14.8.4.3.3 (List Elements) in PDF 1.7 (ISO 32000-1)

• PDF and Accessibility

• G115: Using semantic elements to mark up structure

Procedure

1. For a list in a PDF document, verify in one of the following ways:

   • Read the PDF document with a screen reader, listening to hear that list is read correctly when reading the content line-by-line.

   • Use a tool that is capable of showing lists to open the PDF document and view the list to check that it is correctly structured.

   • Inspect the tag tree to verify that the list is structured according to the PDF specification.

   • Use a tool that exposes the document through the accessibility API and verify that the list is correctly structured.

Expected Results

• #1 is true

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to notify the user when user input to a field that requires a specific, required format (e.g., date fields) is not submitted in that format.

If the required format is not used, an alert dialog describes the nature of the error in text. This may be accomplished through scripting created by the author (see, for example, SCR18: Providing client-side validation and alert). User agents, such as Adobe LiveCycle can provide automatic alerts (as described in the examples below).

Ensuring that users are aware an error has occurred, can determine what is wrong, and can correct it are key to software usability and accessibility. Meeting this objective helps ensure that all users can complete for-based transactions with ease and confidence.

Resources are for information purposes only, no endorsement implied.

• JavaScript for Acrobat

• G89: Providing expected data format and example
• SCR18: Providing client-side validation and alert
• PDF23: Providing interactive form controls in PDF documents
• PDF10: Providing labels for interactive form controls in PDF documents
• PDF5: Indicating required form controls in PDF forms

Procedure

For each form field that requires specific input, verify that validation information and instructions are provided by applying the following:

1. Check that the format or value that is required is indicated in the form control's label.

2. Use an erroneous format or value and move off the field: make sure that an alert describing the error is provided.

Expected Results

• #1 and #2 are true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

The objective of this technique is to ensure that interactive form controls in PDF documents allow keyboard operation. Interactive PDF forms are generally created using a tool for authoring PDF. Form controls are implemented in PDF documents either as described in Section 12.7 (Interactive Forms) of PDF 1.7 (ISO 32000-1) or as described in the Adobe XML Forms Architecture (XFA).

The types of PDF form controls are: text input field, check box, radio button, combo box, list box, and button.

Form controls allow users to interact with a PDF document by filling in information or indicating choices, which can then be submitted for processing. Users who rely on keyboard access must be able to recognize and understand the form fields, make selections, and provide input to complete the forms, and submit the form, just as sighted users can.

Interactive form controls can be provided for forms created by converting a scanned paper form to tagged PDF or by creating a form in an authoring application such as Microsoft Word or Open Office and converting it to tagged PDF.

However, documents created by authoring applications that provide form design features might not fully retain their fillable form fields on conversion to PDF. Complex forms in particular may not have properly converted form fields and labels when tagged in conversion.

Using Adobe Acrobat Pro with forms in converted documents, you can ensure that form fields are keyboard accessible and usable by:

• Opening tagged PDF documents with form fields and creating interactive PDF form elements with the Run Form Fields Recognition tool.

• Modifying fillable form fields, or adding form fields, using Adobe Acrobat Pro or Adobe LiveCycle Designer.

Using Adobe LiveCycle Designer, you can create forms from scratch.

Resources are for information purposes only, no endorsement implied.

• Section 12.7 (Interactive Forms) in PDF 1.7 (ISO 32000-1)

• Adobe XML Forms Architecture (XFA)

• G202: Ensuring keyboard control for all functionality
• PDF3: Ensuring correct tab and reading order in PDF documents
• PDF12: Providing name, role, value information for form fields in PDF documents
• PDF15: Providing submit buttons with the submit-form action in PDF forms

Procedure

1. For each form control, verify that it is properly implemented by tabbing to each form control and checking that it can be activated or that its value can be changed from the keyboard.

Expected Results

• #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.