Content Contributors: Becky Bernauer, Web and Accessibility Coordinator, MNIT partnering with the Minnesota Department of Health; Rebecca Blomquist, Digital Accessibility Coordinator, Minnesota Department of Natural Resources; Samantha Clayton, Digital Accessibility Coordinator, Minnesota Department of Employment and Economic Development; and Tamara Sawyer, Accessibility Coordinator, Minnesota Management and Budget.

Welcome to part two of our built-in accessibility checkers series. In this article, we explore the Adobe Acrobat Pro Accessibility Checker tool and how it can help you ensure accessibility features are present in your PDFs. 

As we mentioned in part one of this series, we checked with our Digital Accessibility Coordinators (DACs) across Minnesota state agencies who have a combined 40+ years of experience remediating PDF documents. We asked them why they use the tool, how they use the tool for initial testing, and how they address the errors the tool finds. Part one also covered the State of Minnesota Digital Accessibility Standard, which our electronic documents must meet.

Editor’s Note: This article references Adobe Acrobat Pro 64-bit, Continuous Release, version 2024.003.20180. The user experience will vary depending on the user’s version of Acrobat Pro. 

Acrobat Pro’s Accessibility Checker Tool Background 

Adobe claims the checker can test to Web Content Accessibility Guidelines (WCAG) 2.0* and PDF/UA (Universal Access, or ISO 14289) using the software’s Accessibility tools. Within the Accessibility tool is the option “Accessibility Check” which scans an entire document for accessibility issues. 

Note: If you do not have Accessibility as a part of your Acrobat Pro’s tools panel, use the “More Tools” option to review all tool options. 

Under the “Protect & Standardize” section, find the Accessibility tool and select “Add.” 

Our DACs share their favorite features, some challenges and how they address the errors while using the Accessibility Checker tool. 

*The Office of Accessibility is working to update their training pages to include how to make PDFs accessible to WCAG 2.1, Level AA. Check back on our training page later this year. 

Tool Functionality 

Once you have added the Accessibility tool to your Tools panel and found the Accessibility Check option, you can select the checker to scan your document. The Accessibility Checker’s Options dialog box will appear. The default options selected will ensure you are checking all issues the Accessibility Checker scans for (including tags, document structure, document title and more). You can select “Start Checking” and the Checker creates an accessibility report.  

Our DACs’ favorite features: 

• It tests for more accessibility issues than the Word Accessibility Checker tool, so you get a more thorough check. Additional issues reported include identifying missing document title/properties and heading hierarchy failures. 
• It finds issues with tables and recommendations on how to fix them.  
• It allows for adjusting color in the document to meet contrast minimum. 
• It serves as a good reminder to walk the tag tree. 
• It gives a reminder to do manual testing, even if no accessibility issues are found. For example, you will always get a reminder to check the reading order. 

Challenges: 

• It does not check to the State’s WCAG 2.1 standard. 
• It can’t tell if the information provided is meaningful. For example, it can tell an image has alt text, but it doesn’t know the difference between meaningful alt text that helps a screen reader interpret the importance of what is being conveyed visually or placeholder text, “add alt text here,” left by a content creator as a reminder.  
• It can’t tell if a link is functioning properly. 
• It can’t test for everything. You must perform manual testing.

Tool Output 

Once the accessibility check is complete, the Accessibility Checker panel to the left lists the accessibility issues. Select each issue type’s dropdown menu to view the details and make fixes immediately.  

Note: If the Accessibility Report states there are no accessibility issues found, it does not mean your work is done. As mentioned in the challenges section, you must perform manual tests. As you perform manual testing, keep in mind the POUR principals of accessibility. Is the document Perceivable, Operable, Understandable and Robust for the end user? Meaning, can the end user read it in the correct order while using their AT and understand what you’re asking for with no assistance form someone else? If the answer is “no” to any of these questions, then the document isn’t accessible, even if it “passes” the checker. 

Our DACs also provided a checklist to use during a manual review. 

• Make sure headings are marked AND have the correct hierarchy (can view this in the Accessibility tags). 
  • Tags should be structured properly (and in logical reading order), especially tags with complex/multi-layered structure such as tables, lists, links, and form fields. To view the structure of the document, open the Accessibility Tags panel. To view the document’s logical reading order, select tags and their corresponding content is highlighted in the document (just like with issues in the accessibility report).  
  • For our remediation experts, check that lists have the correct components (<L>, <LI>, and <LBody> at a minimum) and tables have the correct components (<Table>, <TR>, <TD> and <TH> for header row). 
• Images must have meaningful alt text (not placeholder) or be marked as an artifact (meaning decorative or background). 
• Properties must be filled out appropriately. 
• Links must function properly and are meaningful. 

Addressing Accessibility Testing Failures 

Becky B: We always try to fix issues in the PDF. We do have to keep in mind the time commitment to make the changes (and the capacity of our team) versus the reach of the audience. Sometimes, we may not address an issue, especially if the issue does not create a barrier to people who use AT. 

Rebecca B: I do my best to fix everything. On the rare occasion I can’t solve the problem, I evaluate its potential to prevent someone from reading or using the document. If it’s minor, I let it go. Otherwise, I keep trying to fix it. 

Samantha C: If there is an issue but it was done intentionally (e.g., white text on white background to provide a tip to screen readers), then the accessibility failure is acceptable. 

Tamara S: I fix all issues that may pose a problem to the end user. There are times that I choose to ignore a failure. This is usually when it has been done intentionally. 

Final Takeaways 

While tools are excellent to help aid the testing process, having a knowledgeable person perform manual testing is also a necessity to ensure you capture all accessibility failures for your documents.  

We hope this article provides another tool you can add to your repository to ensure accessible digital content for everyone! In case you missed it, we also covered recommended testing tools for web pages in our April 2024 article “Website Accessibility Testing.” 

Additional Resources

• WCAG 2.1 Quick Reference Guide
• Office of Accessibility PDF 101 Training 
• Adobe Acrobat Pro Accessibility Quick Card (PDF)