# Tagged PDF

Canonical page: https://districtproof.io/resources/glossary/tagged-pdf

A PDF that includes structural information such as headings, paragraphs, lists, and tables.

By [Nilesh Gadekar, Founder](https://districtproof.io/about#founder) · Last reviewed November 4, 2026.

## How to use this term in a district project

Tags describe document structure, but their presence does not show that the structure is correct. A heading can be misclassified, a table can lack meaningful header relationships, or the reading sequence can be confusing. Review the tags against the actual information and intended use, then record the methods and coverage used.

Illustrative district scenario

### A district example

A menu has tags, but the sequence groups all dates separately from meal details. A reader still needs the relationships corrected to understand the document.

## A useful review question

Do the tags represent the document’s meaning and order, or do they merely exist?

## Continue with a practical guide

[Explore the related DistrictProof guide or service](https://districtproof.io/services/pdf-remediation), or return to the [full accessibility glossary](https://districtproof.io/resources/glossary). Technical criteria and legal obligations should be checked against the applicable primary references and the agreed review scope.

## Start with the structure behind the page

A district PDF often begins as a letter, agenda, handbook or budget assembled for visual reading. A tagged PDF adds a structural layer that identifies the roles of its contents. That layer helps software distinguish a heading from an ordinary paragraph, a list from a collection of separate lines, and a data table from text positioned in a grid. The practical question for a district is whether that structure matches the information it is publishing. An export setting that says tags were created is a useful starting point for review, rather than the end of the publishing process.

## District example: an enrollment information pack

Imagine a fictional district publishing an enrollment pack with an introduction, required-document list, transportation table and several links. A parent should be able to find the required-document section without reading every introductory paragraph. The list should preserve which items belong together. Transportation information should keep the school, route and contact details connected. During review, the team compares those tasks with the exported file. If every line is tagged as a paragraph, the document may look unchanged while losing the navigation that would make the pack easier to use.

## Give the source owner a practical checklist

Begin with the maintained source. Use real heading styles for the enrollment sections, actual list features for requirements and a straightforward table for route information. Supply image descriptions while the author still knows their purpose. Export the file, then review the resulting structure and the sequence in which it is presented. The source owner handles questions about meaning, such as an ambiguous transportation abbreviation. The accessibility reviewer handles the structural repair. Keeping those responsibilities clear prevents a technical reviewer from guessing at district policy or silently changing substantive instructions.

## Review the assembled version

A packet assembled from several tagged files needs another check after merging. The returned file should retain understandable navigation, a sensible reading sequence and working links. Page numbers and attachment names should match the actual packet. A visually correct cover does not establish that the attachments are structured correctly. Ask the reviewer to identify the file version used for automated checks and human screen-reader review. If the board office later replaces an attachment, give the replacement a new version and return it to the review process rather than reusing the previous evidence entry.

## Make acceptance and future updates easier

Keep the maintained source, final PDF, delivery manifest and review record together in the handoff. Record any content decisions that still belong to the district, such as an unexplained image or a missing source. After posting, confirm that the public URL serves the reviewed version. A short source-author checklist can reduce repeated repairs in next month’s edition. When requesting a quote, include representative tagged files as well as difficult examples; the presence of tags does not reveal the amount of corrective work. Ask what is included in source repair, final-file review and correction handling before comparing prices.