Tagged vs. Untagged PDFs: How to Tell What You’re Actually Starting With

Man in a suit looking at computer thinking about tagged vs untagged PDF

If your organization has a large PDF library, one of the first questions you need to answer is deceptively simple:

How many of these PDFs are already tagged?

The answer can have a major impact on your accessibility plan. A library full of well-structured PDFs is a very different project from a library where most documents are completely untagged.

But there is a catch. “Tagged” does not automatically mean “accessible.”

A PDF can contain a tag tree that looks impressive at first glance and still have problems with its reading order, headings, lists, tables, images, or other content. Automated tools can also give you a false sense of compliance by identifying the presence of tags without telling you whether those tags accurately represent the document to the people using assistive technology to read it.

Before you start estimating remediation time, assigning work, or deciding what tools you need, take some time to understand the condition of the PDFs you already have.

Start with a simple question: Does the PDF have tags?

Adobe Acrobat makes it relatively easy to determine whether a PDF has a tag structure.

Open a PDF and locate the Tags panel. In current versions of Acrobat, you can find it under the navigation pane or through View > Show/Hide > Side Panels > Tags.

If the PDF has no tag structure, Acrobat will display “No Tags Available.”

If it is tagged, you will see a hierarchy of elements underneath the document root.

For example, a simple document might contain:

Document
→ H1
→ P
→ H2
→ P
→ L
→ Table

The specific tags will vary depending on the document, but seeing a hierarchical tree tells you that some structural information has been added to the PDF.

If you see “No Tags Available,” you have a completely different starting point. The document will need its structure created rather than corrected.

That distinction matters when you’re trying to estimate the work involved.

Don’t stop when you find a tag tree

This is where a basic PDF inventory can become misleading.

Suppose you open 100 PDFs and discover that 80 of them have tags. It would be tempting to conclude that only 20 need remediation.

You cannot make that assumption.

Those 80 tagged PDFs could range from well-structured documents that need very little work to PDFs where an automated tagging process created a full but inaccurate tag tree.

Spend a few minutes inspecting the structure of several representative tagged PDFs before classifying your entire library.

You are not trying to perform a complete accessibility review yet. You are trying to determine what kind of starting condition you are dealing with.

What to look for in the Tags panel

Open the tag tree and expand several levels.

First, look at the overall structure. Does it match the document you are looking at?

A typical report might have a title, several headings (H1, H2, etc), paragraphs (P), lists (L), tables (Table), and figures. The tag tree should reflect those elements.

For example, you might expect something along the lines of:

Document
→ H1
→ P
→ H2
→ P
→ H2
→ L
→ Table

Now compare that with what is actually there.

If almost everything is tagged as P, that is useful information. The PDF is tagged, but its semantic structure may be weak.

If headings are consistently identified as headings, lists appear as lists, and tables appear as tables, you may have a much stronger starting point.

Check the headings

Find a few headings in the document and then find their corresponding tags.

Does text that visually functions as a heading have an H1, H2, or other appropriate heading tag?

A common problem is a document where every piece of text has been tagged as a paragraph, including content that clearly functions as a heading.

That means the PDF has tags, but the tags are not telling assistive technology enough about how the document is organized.

Check the lists

Find a bulleted or numbered list.

In the tag tree, a properly structured list should generally appear as a list with list items beneath it, rather than a collection of unrelated paragraphs.

For example:

L
→ LI
→ LI
→ LI

If you see three paragraph tags where you expected a list, flag the document for closer review.

This is particularly useful when auditing reports, policies, procedures, and instructional materials, where lists are common.

Check the tables

Find at least one table if the document contains them.

Does the tag tree actually identify it as a Table?

If it does, expand the tags.

You should see rows and cells beneath the table structure. Header cells should be distinguished from ordinary data cells.

Do not try to determine every table relationship during your initial library audit. At this stage, you mainly want to identify whether the document contains simple or complex tables that could require additional remediation work.

A 20-page text document and a 20-page report containing multiple merged-cell tables are not equivalent remediation projects.

Check the figures

Look for images, charts, graphs, maps, and other meaningful visual content.

Do they appear in the tag structure as figures?

If a document contains a large number of charts, diagrams, or other complex visuals, flag it. These documents generally require more consideration than a text-heavy PDF, even if both documents are technically tagged.

Use the tag tree to spot obvious reading-order problems

You can also use the Tags panel to get an early indication of whether a document’s reading order may be problematic.

This matters particularly for PDFs with:

Multiple columns
Sidebars
Callout boxes
Text positioned around images
Brochures
Newsletters
Complex reports
Forms

Look at the sequence of tags and compare it with the order in which the content is supposed to be read.

Imagine a two-column article. The logical sequence might be the complete left column followed by the complete right column.

If the tag tree jumps from the left column to a sidebar, back to the left column, and then over to the right column, that document needs closer examination.

You do not need to resolve the reading order during the initial audit. You just need to recognize that tagged does not necessarily mean correctly ordered.

What automated checkers can and cannot tell you

Automated accessibility checkers are useful for auditing a large library, particularly when you need to identify obvious problems quickly.

They can help identify conditions such as missing tags, missing document properties, and other technical issues.

But be careful about treating a checker result as a definitive classification of your PDF.

For example, a tool may recognize that a document contains tags. That does not necessarily mean the tags are accurate.

Consider a PDF containing a report title, several headings, and a list.

An automated tagging process could assign a P tag to every text element. The document technically has a tag structure, but the structure does not communicate the document’s organization very well.

Similarly, an automated process may identify a table as a table without guaranteeing that the header relationships are correct.

This is one reason a PDF library audit should use both automated information and human sampling.

The goal at this stage is not to prove that every PDF is accessible. It is to determine which documents are likely to require little work, which need substantial remediation, and which require a closer look.

Be careful with “false positives”

A false positive in a PDF audit can happen when a document appears to satisfy a requirement because a tool sees the technical element it is looking for, but the element is not actually functioning as intended.

Here are a few examples:

“The PDF is tagged.”

The tag tree exists, but nearly all content is incorrectly tagged as paragraphs.

“The headings are tagged.”

Heading tags exist, but they are assigned to text that is not actually functioning as a heading.

“The table is tagged.”

A table tag exists, but the cells and headers are not structured correctly.

“The image has alt text.”

An image has an alternative text value, but the description is meaningless or does not communicate the information conveyed by the image.

These documents should not necessarily be treated the same way as completely untagged PDFs.

They have an existing structure that may be useful. But they also should not be counted as finished accessible documents.

Create three basic categories

For a first-pass library audit, you can keep your classification simple.

Category 1: Untagged

The Tags panel reports “No Tags Available.”

These PDFs need a structural foundation created before you can meaningfully assess their accessibility.

Category 2: Tagged, but needs review

The PDF contains tags, but your initial inspection reveals obvious structural concerns.

Examples include incorrect heading tags, lists represented as paragraphs, questionable reading order, or documents containing complex tables and figures that need additional review.

Category 3: Tagged and appears well structured

The PDF has a logical tag hierarchy and your initial spot check does not reveal obvious structural problems.

These documents may still require accessibility verification, but they are potentially much further along than an untagged PDF.

This three-category approach is intentionally simple. Your goal is to understand your workload, not complete a formal accessibility evaluation of every document in your first pass.

Don’t audit every PDF individually at first

If your organization has 10,000 PDFs, opening all 10,000 and carefully examining their tag trees is not the best way to begin.

Instead, look for patterns.

Start by sorting your library according to information you already have, such as document type, department, creation date, file size, or whether the document is still published.

Then sample documents from each major group.

For example, if your organization publishes:

Annual reports
Meeting minutes
Policy documents
Application forms
Training materials
Public notices

Pull several examples of each.

You may quickly discover that documents created through the same workflow have similar accessibility conditions.

If 20 recent reports were all generated from the same template and all have the same tagging problems, you have learned something much more useful than the accessibility status of those 20 individual files. You have identified a workflow problem that may be affecting hundreds of documents.

Look for recurring document types

Repeated documents deserve special attention because they can represent both a problem and an opportunity.

Consider meeting minutes.

If your organization publishes them every month, you may have hundreds of PDFs that share a similar layout and structure.

Instead of thinking about each file as a separate remediation project, ask:

How many of these documents are variations of the same underlying structure?

The same applies to recurring reports, agendas, policies, forms, newsletters, and other regularly updated documents.

If the documents are substantially similar, remediation work may be reusable rather than starting from scratch every time.

This is also a good reason to record the document’s turnover rate during your audit. A PDF that is updated every month creates a very different ongoing accessibility workload from a static document that was published once five years ago.

Record what you find

You do not need an elaborate accessibility database to get useful results.

A spreadsheet is enough for an initial inventory.

At minimum, record:

Information	Example
File name	Annual_Report_2026.pdf
Document type	Annual report
Department/owner	Communications
Tagged?	Yes
Initial classification	Tagged, needs review
Tables?	Yes
Complex visuals?	Yes
Forms?	No
Updated regularly?	Annually
Still published?	Yes
Priority	High

The last item is important because not every PDF deserves the same priority.

An outdated internal document that nobody uses should not necessarily receive the same attention as a public application form that thousands of people use every year.

Your first audit should answer five questions

Once you have sampled your library, you should have enough information to start answering:

How many PDFs are completely untagged?

This gives you a rough idea of how much foundational remediation may be required.

How many are tagged but structurally questionable?

These documents may require significant cleanup even though they technically contain tags.

How many appear to have a strong existing structure?

These may require less remediation, although they should still be verified before being considered accessible.

Which document types create the most complexity?

Tables, forms, charts, maps, multi-column layouts, and other complex content can substantially change the effort involved.

How many new or updated PDFs are being produced?

This is the question that prevents an accessibility project from becoming an endless cycle of backlog remediation.

If your organization is creating 500 new PDFs every month, you need a strategy for those documents too.

Why knowing your starting point matters

There is a big difference between saying, “We have 8,000 PDFs that need to be made accessible” and saying, “We audited our library and found 1,500 untagged PDFs, 3,000 tagged PDFs requiring structural review, 2,500 relatively well-structured documents, and 1,000 outdated files that can be removed.”

The second statement gives you something you can actually plan around.

It helps you estimate remediation capacity, prioritize high-value documents, identify recurring workflows, and determine whether your current tools and processes can handle the volume.

It can also prevent you from spending time remediating documents that no longer need to be digitally available.

Most importantly, the audit gives you a realistic picture of the problem before you decide how to solve it.

What to do after the audit

Once you know what you are starting with, the next step is to determine how that work will actually get done.

For a small library of straightforward PDFs, manual remediation may be manageable.

For a large library containing thousands of documents, complex layouts, recurring reports, and a steady stream of new PDFs, you may need a more scalable approach.

That could include prioritizing documents for remediation, establishing accessibility requirements for new content, giving content creators the ability to remediate their own PDFs, using automation to accelerate repetitive work, or combining several of these approaches.

The important thing is to make that decision based on the PDF library you actually have, rather than an estimate based solely on the number of files.

The bottom line

Before you can build a realistic PDF accessibility plan, you need to know your starting point.

Open a sample of your PDFs in Acrobat. Check whether they have a tag structure. If they do, expand the tree and look at whether headings, lists, tables, figures, and reading order appear to be represented logically.

Then compare what you see with the results from your automated tools. If the two tell different stories, investigate rather than automatically assuming the PDF is accessible.

And remember that “tagged” and “accessible” are not interchangeable terms.

A library audit is not the same thing as a final accessibility check. It is an inventory and triage exercise that helps you understand the size, complexity, and condition of your workload.

Once you know what is actually in your PDF library, you can make much better decisions about what needs to be remediated, what should be prioritized, and how your organization can keep new PDFs from creating the same problem again.