Test a PDF with a screen reader

Name the screen reader, version, PDF reader, operating system and file version. A PDF may behave differently in an embedded browser viewer and a standalone reader. Record where the observation was made.

NVDA’s user guide explains browse-mode and table navigation. Learn the current commands and confirm the active mode before treating an absent response as a document failure.

Sources: [1]

Choose a PDF reader supported by the screen reader and open a document whose content you know. Establish that focus is in the document and the appropriate reading mode is active. If a command fails, first exclude focus in a menu, search field or another window.

In NVDA browse mode, H moves to the next heading, T to the next table and K to the next link; Shift reverses direction. NVDA+F7 opens an elements list. The NVDA modifier is configured by the user, often Insert or Caps Lock. Support depends on the document and reader; consult the manual and actual environment.

Within a table, Ctrl+Alt with arrow keys supports cell navigation in compatible environments. Listen for the value and the context needed to interpret it. The goal is meaningful access, not one exact spoken phrase: for example, understanding that 105 means hours for February.

Start narrowly: find a section through headings, read its first paragraph and follow a link. Move to harder tasks once this works. Trying every command at once makes it easy to confuse unfamiliarity with the tool and a document defect.

Sources: [1]

• Find the Results section by headings without reading from the start.
• Read across a page break and follow both columns.
• Establish the year and unit for a table value.
• Understand a chart’s conclusion and find its exact values.
• Find and activate a link to an appendix.

Continuous reading can expose interruptions and sequence errors. But people rarely read long reports only that way. Also jump directly to sections, investigate individual values and return from appendices. These tasks exercise structure as a navigation aid.

Write the expected result before testing. For a grant guide, find the closing date and eligibility condition; for an annual report, compare two years’ results with the correct unit. The document owner should confirm the answer so the tester does not inadvertently accept a misinterpretation.

When a barrier appears, record the starting point, command, location and observed result. Explain what information was missing. Note any visual assistance needed to continue. Being shown the correct cell is different from navigating independently.

Successful screen-reader tasks do not assess contrast, colour use or every magnification need. Combine methods and state the test’s scope. Several clear, bounded observations are more useful than a general claim that the file works for everyone.

Imagine a report with an introduction, a results section and the monthly table used in our examples. The following is a proposed record, not evidence of completed testing. Enter observations only after someone performs the tasks in the named environment.

For example: Expected: the cell can be understood as 84 hours in January. Observed: only 84 is announced in the chosen setup. Record how you reached it and what happened. This gives the person repairing the file something to reproduce.

This illustrates a test record; it does not claim that your document has been tested.

If heading navigation misses a section, first check focus and reading mode. Try another known heading in the same file. If none work, investigate the environment or overall structure. If one is missing, examine that particular object.

Table settings can affect when and how headers are announced. Record settings material to the observation. Readers need a workable way to obtain the right information, while document structure must meet applicable requirements. A special setting should not conceal a broken association.

Try another reading environment where useful to isolate the cause. Different behaviour is relevant evidence, but does not independently establish which component is defective. Compare tag structure, requirements and tool documentation, retaining both observations.

After repair, repeat the original task from the same starting point and check nearby content potentially affected. This establishes that the previous barrier was retested, rather than merely noting that the file now sounds different.

An inexperienced tester can find obvious faults but may miss barriers or struggle with the tool itself. For important deliveries, review by an experienced screen reader user is valuable. Record who performed the test, which tasks it covered and its limitations.