Are your accessibility tools accessible?

 In Articles, PDF Accessibility, Software
Male designer carefully reviews colorful charts on his computer screen.

The Accessibility of Making PDFs Accessible

We post articles, blogs and white papers about accessible PDF creation, remediation and testing. But there’s another aspect of PDF accessibility to consider: How accessible are the tools you are using to do all of this work? 

Illustration of a disabled man with a can surrounded by other symbols of disability: an eye, an ear, hands signing and glasses.

First, let’s talk about the accessibility “elephant in the room.” When it comes to testing or remediating PDFs, there are certain things that people with disabilities may find very difficult, or even impossible, to do. For example, blind people may not be able to verify the accuracy of the alternative text assigned to an image. Similarly, a colorblind person might have difficulty determining if color is the only way that information is being conveyed. That being said, when it comes to PDF remediation and testing, people with disabilities can (and often do) most of the work, so the tools they use need to be accessible.

According to the W3C, there are two tools capable of PDF remediation to achieve WCAG 2.0AA conformance. (Follow this link to the W3C Techniques page and then navigate to “Accessibility Checking and Repair.) The tools mentioned by W3C are Adobe Acrobat and CommonLook PDF. So, let’s look at the accessibility of those two tools.

Adobe Acrobat

Adobe provides an online VPAT (Volunteer Product Accessibility Template) which outlines the accessibility of their products. When it comes to the application itself (Section 1194.21), Adobe mentions that “many user interface controls and functions in Adobe Acrobat Pro DC can be executed via the keyboard with some exceptions…” Of course, keyboard functionality is absolutely critical for someone using a screen reader (it is also critical for individuals who struggle with using a mouse). Acrobat mentions, however, that there are exceptions or limitations to the keyboard functionality.

Here is a list of the functionality that is not available when using the keyboard with Adobe – and all of these things are functions that a remediator or tester might need:

  • Tools involving the positioning and/or manipulation of elements using the mouse,
  • Tools that require drag and drop functionality and
  • Tools involving mouse selections, such as the Snapshot Tool and the TouchUp Reading Order tool (now just the “Reading Order” tool).

In addition, their VPAT states,

“Adobe Acrobat Pro DC provides identity, operation and state information to Assistive Technology throughout the interface with some exceptions.”

That’s like a building with a ramp that goes most of the way – but not all the way – to the door. When it comes to accessibility, close does not count.

Finally, in part “L” of Section 1194.21, Adobe states,

“Form controls in PDF documents support full access to elements and functionality required for completion of the form. However, some dialogs, panels and tools in the Acrobat user interface do not provide name, role and state information for controls and are not fully keyboard accessible.”

Again, either it’s accessible or it’s not.

CommonLook PDF

The other tool mentioned by the W3C is CommonLook PDF. Similar to Adobe Acrobat, CommonLook provides a VPAT for CommonLook PDF  on their website. If you compare the two VPATs (Acrobat and CommonLook PDF), you will notice that they are somewhat different. This is because, when Section 508 was “refreshed” to align with WCAG 2.0AA, the VPAT template was also updated. CommonLook uses the newer template whereas Adobe’s VPAT is based on the original VPAT (which, itself, is based on the outdated and less rigorous WCAG 1.0 Priority 1). That being said, let’s explore the accessibility of CommonLook PDF.

Based on the WCAG 2.0AA VPAT, CommonLook PDF “Supports” 38 of the 55 checkpoints (meaning that “the functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation”). Of the remaining checkpoints that are not “supported,” 11 of them are not applicable to the software (for example, 1.2.4 and 1.2.5, concerning captions and audio description because the software does not include any live audio or audio functionality). There are 4 checkpoints that are “Supported with Exceptions” which means that “Some functionality of the product does not meet the criterion.” Most of these instances are for situations that were identified at the beginning of this article – needing sight or being able to perceive color, etc., to remediate PDFs. For example, Criteria 302.1 – Without Vision, states in the description,

“When an activity requires that the user use vision to provide information (for example, provide alternative text to a Figure) the application is not able to provide an alternative method to help the user identify the image.”

In other words, if a remediator needs to provide alternative text for an image, CommonLook alone cannot tell the remediator what the image is to assist them in assigning Alt-text. Similarly, Criteria 302.9 identifies that some people with certain cognitive or language difficulties may have a hard time understanding some of the checkpoints in the standards. (On a side note, I have personally been lamenting for years that various accessibility standards themselves fail the “Understandability” principle of accessibility.) CommonLook users and graduates of CommonLook training are well aware of its keyboard functionality, not only to make it accessible but also to vastly increase the speed, accuracy and efficiency when using CommonLook to remediate PDFs.