Skip to main content :::
:::

How to Read PDF Accessibility Results and Re-Test Fixes

Use hypothetical results for a two-page PDF to interpret tags, images, field tooltips and page sizes. Separate DevCheck’s findings from manual checks, then repair and re-test the document.

Last updated:

Summary

  • First confirm that analysis completed, then match the results to document pages. Counts are not issue totals.
  • Tags do not establish correct reading order, and image counts do not establish complete text alternatives.
  • Repair the source or PDF, re-check the exported file, and test actual reading and form interaction.

Start with the scope of the result

This guide is for readers who already have PDF results and need a next step. If you have not selected a file yet, use the linked PDF checker instructions below. DevCheck lists information available through PDF.js parsing, not a conformance decision for the document.

Record the file name, document version, tool and check date. If a limit, parsing error or cancellation stops analysis, mark the check as incomplete rather than recording zero issues. The example below is hypothetical, not a tested document or customer case.

Example: what needs review in a two-page registration document?

Suppose a two-page registration document shows 1 / 2 tagged pages, page 2 without detected tags, 3 images, 4 form fields, 1 missing tooltip and 2 page-size variants. Match each clue to the document; do not add these numbers up as “11 errors”.

  • Tags on 1 / 2 pages: inspect page 2 for meaningful content and check whether export preserved its structure. Page 1 still needs review of headings, tables and reading order despite having tags.
  • 3 images: the tool counts specific image-paint operations, not necessarily three unique images or three missing alternatives. Distinguish informative images from decoration, then review the corresponding alternatives manually.
  • 1 missing tooltip: use the field list in a PDF form editor to locate fields without descriptions. The other three tooltips may still be unclear; try completing the form with a keyboard and screen reader.
  • 2 page-size variants: check for an intentional landscape appendix or similar layout. Mixed sizes alone are not an accessibility failure; verify that content is not clipped and remains usable.

Checks not listed are not checks passed

DevCheck does not validate individual PDF image alternatives, heading hierarchy, table relationships, reading order, text contrast or OCR text quality. Its link-annotation count does not establish that link wording and destinations are correct.

For a scanned document, first check whether accurate text is available. OCR is a starting point: recognized text and structure still need review. Use appropriate PDF tools and assistive technology to check sequence and interaction in multi-column documents, tables and forms, not just tag counts.

Turn a clue into an actionable finding

Avoid reporting only “the PDF is inaccessible”. After manual confirmation, a useful finding might say: “The Email field on page 2 receives keyboard focus, but its name is not announced in the specified PDF reader and screen reader. Expected: Email. Review the field name and re-test.” Record this as a finding only if you actually verified it; otherwise mark it for review.

Include the page number, file version, steps, expected and actual results, and PDF reader and assistive-technology versions. Use fictional input; do not include real personal data in screenshots or public reports.

Repair and re-test, not just a clean warning list

When you have the source, correct headings, alternatives, language and structure there, then export with tags preserved. Use a PDF editor when only the PDF is available or export leaves problems. DevCheck does not repair or tag files automatically.

Select the exact PDF intended for publication and analyze it again. Then review the content in a PDF reader, check Tab/Shift+Tab through links and forms, and test screen-reader names and reading sequence. W3C PDF3 provides reading- and focus-order checking methods; its source is linked below.

Keep “fix verified”, “manual review needed” and “not yet tested” separate. Expected counts do not establish PDF/UA or WCAG conformance. Prioritize documents needed for applications, queries or essential information; low traffic does not mean nobody needs access.

Next checks in this workflow

Choose a follow-up task that applies to your page. PDF checks are needed only when documents are part of the task; a fix still needs retesting.

  1. Turn findings into a remediation plan

    Web accessibility remediation plan

    Organize next steps by user task, impact scope, owner, repair level, and re-test method.

Related pages