By: Tamara Sawyer, Minnesota Management and Budget and Jennie Delisi, Office of Accessibility

This is the second article in a two-part series to help you learn how to make PDFs that conform to WCAG 2.1. As a reminder, this series only covers the success criteria added for WCAG 2.1 and are A or AA. If you want information about those covered for WCAG 2.0, be sure to visit the Office of Accessibility’s Accessible PDF Training Modules. 

Last month in Part 1, we shared basic information about how to create simple PDF documents. This month we cover what you need for more complex documents. This includes documents that use JavaScript, InDesign, and that have complex charts and graphs. And, because we know you want more specifics, read to the end! We include resources to use while you work.

As a reminder, the state of Minnesota has not yet officially determined if PDFs will be part of the move to WCAG 2.1. Because you are not the average reader you want to be ready to make your PDFs more usable by everyone without waiting for an official PDF and WCAG 2.1 announcement. You are our favorite kind of reader and we have what you need!

Start By Taking Some Work Out of Your Workflow

Some WCAG 2.1 success criteria will not apply to your PDFs. Knowing this can help you focus on the other parts of WCAG 2.1.

1.3.4 Orientation (AA)

Orientation is the direction of the display of the screen while viewing a PDF. In document terms, this is portrait or landscape. If you are using a smartphone, you may rotate it to better view something onscreen. In most cases, the person viewing the PDF controls this, not you (the author or remediator). If you find a way to restrict the orientation of the PDF, don't use it. People should be able to view the document in the orientation that works best for them.

1.4.12 Text Spacing (AA)

Have you ever opened a document and found the words felt too close together to easily read them? That it would help to have the letters separated a little more? This success criteria’s goal is to ensure that everyone, especially people with reading and vision challenges, can change line height, spacing following paragraphs, and letter and word spacing while reading the PDF.

This requires the use of “markup,” something available for technologies like web pages. At the time of this article, this is not something a person can control when they create or remediate PDFs. Thinking about white space while creating your document is important, but it does not provide the end user control of how the white space displays on their screen while they are reading the PDF. Hopefully this will become an option in the future for people who read PDFs.

2.5.4 Motion Actuation (Level A)

Success Criteria 2.5.4 states “functionality that can be operated by a device motion or user motion” such as shaking or tilting the device “can also be operated by user interface components.” It goes on to say that the user must be able to disable the motion control.

These actions are set up and controlled within the mobile devices, so does not apply to PDFs.  Most or all functions that can be performed by motion activation can also be performed by either the keyboard or the PDF interface. An example of this would be using the Ctrl+Z keyboard shortcut or the Undo option available in the Edit tab, to remove any text just added to a form field or to remove a check added to a check box.

Considerations for Complex PDF Documents

Next, let’s discuss the situations going beyond more simple documents. Think about times where you use:

• Form controls (radio buttons, check boxes, dropdowns, text fields).
• Buttons.
• Electronic signatures.

And, think about people using your PDF in more modern ways, like on a smartphone. This next section covers these more complex situations.

1.3.5 Identify Input Purpose (AA)

Many forms ask you for the same information such as your name, address, and telephone number. Re-typing the same information increases your chance of making a mistake. This may be especially true for people with certain types of cognitive disabilities, including people with memory issues or dyslexia. And, if typing is difficult, re-typing the information is time-consuming and frustrating. This success criteria’s goal is to make it easier to have information added for users if they want this option.

This success criteria technically does not apply to PDFs. You cannot add the same coding to a PDF that you can for web pages that must follow this one. But, there are things you can do to improve your user’s experiences. In the desktop version of Acrobat, there is a feature called Auto-complete. We have more information about this in the handouts from our AccessU presentation (links at the bottom of this article). The person completing your PDF form can use the option to have content they have entered in other forms available to add from a list.

This feature works best if you select the appropriate format category in the format tab. For text fields, you can go to the format tab and select the appropriate format category. This makes it easier for the user to select the best option for the text field. This is not a requirement but shows your end user you are making sure they can complete your form.

1.4.13 Content on Hover or Focus (AA)

Tooltips appear in PDFs when you move your mouse over a form field. Today, the PDF viewing software controls the visual appearance of tooltips. You cannot control how they display – you can only control what you put into them. Because this success criteria is about how they display you are not required to ensure this works for WCAG 2.1.

However, the choices you make for these tooltips do impact your end users. The spirit of the success criteria is important to consider. 

When the tooltip is the same as the visible label, this is not an issue.

You must provide a tooltip for your form fields because it provides the accessible label for people using assistive technologies. Sometimes people add additional information in the tooltip. People using magnification may have difficulty using tooltips. Some people with cognitive disabilities who may need the additional information may not notice it. 

Best practice: include the additional information in both the visible label and the tooltip.

2.1.4 Character Key Shortcuts (A)

A character key shortcut allows an end user to use a key on their keyboard to complete an action. Most of the time this does not happen in PDFs. In rare cases, a PDF creator may add a custom keystroke script. We have not tested this against success criteria 2.1.4. We advise you test this option if you decide to use it.

2.5.1 Pointer Gestures (Level A)

This success criteria refers to touch screen devices where the user may have to: 

• Move their fingers or a pointer (such as a stylus or mouse) from one point to another (such as a swipe).  
• Use two or more fingers to complete an action (such as pinch to zoom or a double tap). 

To pass this criterion, if the end user needs any pointer gestures to complete an action, there must be a secondary method available. 

These gestures affect people:

• Who use speech input.
• Who use eye-gaze technology.
• Who use a single pointer device (switch or foot mouse).
• With motor disabilities who may not be able to perform these gestures. 
• With some cognitive disabilities (may not understand or be able to complete the complex gesture or multi-pointer action).

Examples for path-based gestures for PDF might include (on a mobile device):

• Using a pinch gesture to zoom in/out. 
• Using a swipe motion to move to the next page.
• Signing a PDF form by drawing a signature or using drag and drop to place a signature.

Example 1:

The controls on the Adobe Acrobat PDF interface include: 

• The up/down arrows replace the swipe gesture to change pages. 
• The spyglass with the + sign replaces the pinch to zoom gesture.

Example 2:

A check box with boilerplate language and a text field takes the place of a path-based e-signature in which the person must: 

• Use a stylus or their finger to sign a document.
• Use drag and drop to place a signature into a signature field. 

2.5.2 Pointer Cancellation (Level A)

Have you ever accidentally clicked on the wrong button? People making PDFs that use buttons and form controls created with JavaScript should review this criterion.  Success criteria 2.5.2, Pointer Cancellation requires at least one of the following criteria to be true:

• Mouse-down pointer event (when you physically push a mouse button down) does not execute the function.
• Event is canceled if the mouse is moved off object/drop area prior to mouse-up action (releasing the mouse button).
• Down-event activation (pushing a keyboard key down) is ok for keyboard-only use. Keyboards usually only work with down-event activation. The Backspace or Delete key then functions as an undo button.

Example 1: A user uses mouse-down to select an option in a multi-list form field. The user changes their mind, moves mouse away from the option prior to the mouse-up action, and the option is not selected.

Example 2 (images below): A user accidently presses the mouse button on the Clear button instead of the Print button (image on left). They move the mouse off the Clear button before releasing the mouse button (mouse up). The form retains the information (image on right).

When creating a button or other interactive form field, be sure to choose both Mouse Up and On Blur from the Select Trigger option on the Actions tab. This allows people to select the action with a mouse, button, keyboard, or a tap (on a touch screen). 

 2.5.3 Label in Name (Level A)

This success criteria states that the name of a visible label or text on the document page must be the same as the interface component labeling. In the case of a PDF form, this just means that the tooltip must be the same as the text found within the form text. This allows someone using a speech-input device to interact with your form fields. 

There are two samples on the page. The sample on the left passes this success criteria because both the button text and the tooltip say “Print.” Someone using a speech input device can give the command “Print” and the expected behavior, printing the page, will happen.

The image on the right shows a form field. The text on the document page is “Date” but the tooltip is “MM/DD/YYYY.” This fails the success criteria, as the word “Date” is not in the tooltip. The form author could have started with the word “Date” and then added MM/DD/YYYY to give the end user more information. Even better, both the form text and the tooltip could have both the date and the expected format.

4.1.3 Status Message (Level AA)

Success Criteria, 4.1.3 Status Messages states “In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.” Although PDF status messages do not really apply to this criterion as they cannot be “programmatically determined through role,” there are times when an end user may receive a status message. Let’s look at when this may happen and the resulting user experience.

You create a PDF form with a text field for Zip Code. Being a diligent form creator, you open the Text Field Properties dialog box, go to the Format tab, and then under “Special”, choose “Zip Code”. Choosing a format is good because when the end user chooses to have form fields automatically filled for them, non-zip code selections will not enter into the form field. This makes it easier for some people with cognitive impairments such as dyslexia and is a real time saver for someone with motor impairments using something like eye-gaze technology.

However, as seen in the image on the right (below), if the end user types in the incorrect number of digits, they do receive a warning. There are a couple problems with this:

• We cannot find a way to block the status message from receiving focus.
• The status message includes the name field of the form control – not the tooltip, and the name may be meaningless (such as Text17).

There are some ways you can prevent the end user from receiving a message they cannot understand. Keep in mind - technically you do not need to do this to satisfy 2.1, as it relates to HTML forms. However, if you wish to improve the user experience, you can:

• Not use these types of controls and formatting. This is NOT a preferred method, and we are NOT recommending it.
• Change the name of the “Name” field in the Properties Dialog box that produce these status messages. This takes manual work on the off chance someone receives a message they do not understand.

What’s Next?

If you have been counting, we’ve only covered eleven of the twelve new success criteria. Why is that? Well, Success Criterion 1.4.10, Reflow Testing (AA) has some challenges we haven’t quite worked out yet. We are currently doing more testing and will share our results with you next month. 

In the meantime, we hope you have enjoyed learning about the upcoming changes and how to handle them. Here are some resources if you are wanting more than what is here: 

• /mnit/assets/OvercomeYourWCAG21PDFAndInDesignFears_Sawyer_Delisi_tcm38-582034.pdfAccessU Presentation Recording Handouts for Overcome Your WCAG 2.1 PDF and InDesign Fears (PDF)
• /mnit/assets/AccessU_MN_Presentation_2023_live_accessible_tcm38-582035.pdfAccessU Presentation (Live Portion) for Overcome Your WCAG 2.1 PDF and InDesign Fears (PDF)

In addition, we are adding more resources as we do more testing and research. Our goal is for you to be comfortable with WCAG 2.1. The best way to receive these new resources as they become available? Subscribe to the newsletter!