FAQ: Testing Accessible PDFs 

Checking PDF accessibility requires a combination of automated evaluation and hands ‑on inspection. While tools can identify many technical issues, accessibility ultimately depends on whether users can successfully read and navigate the document using assistive technology.

• Run the Accessibility Checker in Adobe Acrobat Pro to identify common issues.
• Manually review tags, headings, lists, tables, links, and alternative text.
• Verify document language and title metadata.
• Test the PDF with one or more screen readers to confirm real ‑world usability.

Automated tools are useful for quickly identifying many accessibility errors, especially in large documents. However, they can only determine whether required structures exist—not whether they are meaningful or usable.

• Common automated tools include:
  • Adobe Acrobat Pro Accessibility Checker
  • PAC — PDF Accessibility Checker
• Automated testing should always be treated as a starting point, not a final validation.
• These tools detect missing tags, contrast issues, and structural errors.

Testing with screen readers is essential because accessible PDFs are designed to work with assistive technologies. Different screen readers interpret PDFs slightly differently, so testing across platforms improves reliability.

• On Windows:
  • NVDA (free and widely used)
  • JAWS (commercial, commonly used in enterprise environments)
• On macOS:
  • VoiceOver, built into the operating system
• Testing with at least one Windows screen reader and VoiceOver is considered best practice.
Use latest – 1 version for testing PDFs as generally users won’t be using the latest version.

Screen reader users do not interact with PDFs visually. Instead, they rely on structured navigation, keyboard commands, and the underlying semantic tags of the document.

• On Windows, users typically open PDFs in Adobe Acrobat Reader with NVDA or JAWS.
• On macOS, PDFs may be read in Preview or Adobe Acrobat Reader using VoiceOver.
• Users rely on different keystrokes to access the PDF, a well-structured and tagged document ensures a smooth screen reading experience.

Adobe Acrobat settings can affect how PDFs are presented to assistive technologies. Using the correct configuration ensures that testing reflects how screen reader users experience the document.

• On Windows, make sure that “Disable new Acrobat Reader” option available under “Menu” is selected.
• Launch the “Accessibility Setup Assistant” option available under “Edit>Accessibility”. Here you will be presented with different options based on different assistive technologies.
• Select “Set options for screen readers” and follow the on-screen instructions. As you proceed further in the Accessibility Set up Assistant dialog, use the default options for a smooth screen reading experience. You can opt to select the “Only read the currently visible pages” option if you want your screen reader to read one page at a time. Other than this all the default options work well with different screen readers.

Tip: You can launch the Set up Assistant any time by pointing to “Edit” menu > “Accessibility”.

The Adobe online help site has useful information about Reading PDF with Reflow and Accessibility Features. Information about reading PDFs with screen readers is available too!

In most cases, screen readers can be used with default settings. Accessibility testing should reflect a typical user setup rather than customized or advanced configurations.

• Use standard reading or browse modes (e.g., Browse Mode in NVDA or Virtual cursor mode in JAWS).
• Avoid altering speech verbosity unless required for analysis.
• Focus on whether the document works without special configuration, as most users rely on defaults.

Screen reader navigation is based on document structure, not visual layout. Well‑tagged PDFs allow users to move efficiently through content rather than reading from start to finish.

• Navigate by headings, links, lists, or form fields using keyboard shortcuts.
• Use arrow keys for continuous reading.
• Jump directly to sections using heading navigation commands or navigate using document Bookmarks.
• Poor structure forces linear reading and degrades usability for screen reader users.

Semantic elements allow users to scan and understand the document quickly. Without proper tagging, users must listen to content sequentially, which significantly increases cognitive load.

• Headings provide document structure and enable quick navigation. Use either heading quick navigation keys or pull up list of headings.
• Images are announced using alternative text or skipped if decorative. Screen readers will identify the element as either “graphic” or “image” followed by the alternate text.
• Lists are announced with beginning/end of list and number of items. Screen readers will also identify nested lists and their nesting levels.
• Links are often reviewed in a links list, making descriptive link text essential. Alternatively, users can jump from one link to another using Tab and Shift + Tab keys.

You can use the standard reading keystrokes of different screen readers to read a PDF document. For example, you can use “Insert + T” to read the document title, “H” to jump to next heading, “G” to jump to next image and so on with NVDA or JAWS on Windows. You can refer to the Cheat Sheet – Screen Reader Commands for JAWS, NVDA – PDF for a full list of keystrokes that can be used to read PDF documents.

Accessible tables rely on correct tag structure rather than visual layout. Screen readers determine cell relationships using the table’s underlying structure.

• Column and row headers must be tagged as table headers (TH).
• Data cells must be programmatically associated with their headers.
• When structured correctly, screen readers announce the relevant header as users move through cells.
• With JAWS and NVDA, use Alt + Ctrl + Arrow keys to navigate between cells and screen readers will read row and column headers if tagged.

Reading order determines the sequence in which content is presented to assistive technologies. A visually correct layout does not guarantee a logical reading order.

• Use the Tags panel, Reading Order tool or Order panel in Adobe Acrobat Pro to check the reading order.
• Compare visual order with the order announced by the screen reader.
• Pay close attention to multi‑column layouts, sidebars, and footnotes.
• Screen reader testing is the most reliable validation method in the case of reading order and automated tools often fall short to identify inaccurate reading order issues.

Screen readers interpret numbers based on formatting, punctuation, and context. Small visual differences can significantly affect how numbers are announced

• Commas, dashes, and symbols influence pronunciation.
• Financial and statistical documents require consistent numeric formatting.
• Clear formatting improves comprehension for screen reader users.

Tip: Each screen reader provides options to customize Speech verbosity for reading numbers, such as read single digits, read pairs and so on to help users.

Mobile screen reader testing is increasingly important as many users access documents on phones and tablets. However, it should be considered complementary to desktop testing.

• Use VoiceOver on iOS and TalkBack on Android.
• Use Acrobat Reader DC to test PDFs.
• Mobile screen readers don’t correctly expose the underlying tag structure.
• Desktop screen reader testing remains essential for full validation.

Read out loud is a text to speech utility by Adobe which reads out text in PDF documents. Read out loud is capable of reading entire document, individual pages, and selected text. It does not rely fully on PDF tags. Read out loud will read text based on its default text to speech settings and it cannot be customized by end users.

• It follows visual layout more than semantic structure.
• It is not equivalent to a screen reader used by people with disabilities.

Read Out Loud can assist with basic reviews but should never be used as a testing tool for verifying accessibility.

• Useful for quick checks of obvious reading order issues.
• Helpful for people who don’t use screen readers to review content.
• Not sufficient for WCAG or PDF/UA conformance testing.
• Screen reader testing will provide accurate insights when performed by native users.

Navigation using Read Out Loud is limited and does not reflect how screen reader users interact with documents.

• Start and stop reading from the toolbar.
• Move forward or backward by page.
• No means to quickly navigate between headings, lists, or links.
• Reads the text content but doesn’t identify the type of element, heading, image, list, link or table. So, everything is just text for users.

Differences in output highlight the distinction between assistive technologies and text‑to‑speech utilities. These differences often reveal underlying accessibility problems.

• Screen readers use tags and document semantics.
• Read Out Loud relies on visual appearance and text flow.
• Differences often indicate incorrect tagging or reading order.
• Screen reader behaviour should always be prioritized during testing as it reflects the document’s tag structure.