How to tag a PDF: a step-by-step guide

Tagging gives a PDF a structure that screen readers can follow. But a tagged file can still fail an accessibility review if its reading order, images, tables, or form fields are wrong. Use this five-step process to tag the file, test the result, and choose a better workflow when the backlog is too large for one document at a time.

Step 1: Check the PDF before you create tags

The first step in learning how to tag a PDF is to inspect the source file. Open the PDF in a full-featured PDF editor and ask what kind of file you have. Is the text selectable? Are the pages scans? Does the file contain charts, tables, links, or fields?

Try to select a sentence with your cursor. If you can’t select words, the page may be a scan or an image-only PDF. That changes the order of work. You’ll need OCR before you can build a useful tag tree.

Next, look for obvious source problems. Check the page count. Scan for blank pages, decorative lines, watermarks, sidebars, and repeated headers. These items often confuse automatic tagging. A decorative line should usually become an artifact. A line that separates two parts of an instruction may need a real tag or nearby text instead.

Run the PDF editor’s accessibility checker before you change the structure. Treat its result as a starting list, not a final verdict. It can point to untagged content, missing alternate text, or document settings. It can’t decide if a heading makes sense in context or if a chart description explains the point.

When the checker highlights untagged content, inspect the matching object in the Content pane. Blank space and decoration can be marked as artifacts. Meaningful text must be tagged. This distinction matters because screen readers skip artifacts, while they need meaningful content in the reading sequence.

Community accessibility guidance describes the same repair path: inspect the highlighted item, mark decorative content as an artifact, tag meaningful content, then run the check again. You can review an example of untagged PDF space if the accessibility checker flags blank areas in your file.

Make a short content map before you start. Write down the title, major headings, lists, tables, figures, footnotes, and links. You don’t need a perfect inventory. You need enough of a map to spot a wrong tag later.

By now you should know whether the PDF is text-based or scanned, which pages contain complex content, and which items are decoration. That knowledge keeps automatic tagging from becoming a blind cleanup job.

Step 2: Open the tags pane and build the document structure

Now build the tag tree that tells assistive technology what each piece of content is. In a desktop PDF editor, open the Tags pane through View, Show/Hide, Navigation Panes, then Tags. If no tag tree exists, choose the accessibility tool that adds tags automatically.

Automatic tagging is a useful first pass. It is rarely the finished file. The PDF editor may read a heading as body text, split one paragraph into several parts, or put a sidebar before the main text. You must inspect the result page by page.

Start at the top of the tree. The first tag should be a Document tag. The main headings and block-level text should sit under it, either directly or inside a useful grouping tag. A character-level tag belongs inside a text block. It should not sit directly under Document.

Use heading tags to show rank. The title is often H1. Main sections become H2. Subsections become H3. Don’t choose a heading tag because the text looks large. Choose it because the text tells the reader what the next block covers.

Skipping a level creates a structural gap. For example, an H1 followed by H3 may confuse users who move through the document by heading. A large bold line can still be ordinary paragraph text if it doesn’t introduce a new section.

Use P for normal paragraphs. Use list tags for lists rather than tagging each line as a paragraph. A list needs the list container plus the right child structure for list items. The exact tree may vary with the PDF, but the parent-child relationship must make sense when read without the page’s visual design.

Keep figures and tables separate from ordinary text. A Figure tag holds an image and its alternate text. A Table tag holds the table structure. Don’t attach an image description to a parent tag that contains unrelated child content. That can cause assistive technology to hide or skip text.

The documentation for editing PDF tags explains how to move, nest, rename, and remove tags in a desktop PDF editor. Use those controls with care. Moving a tag changes reading order, but it may not fix the underlying content placement.

Read the tree from top to bottom. Imagine a screen reader user moving through it with heading commands. If the tree jumps from a title to a footer, or places a caption before the figure, the structure needs work.

The Prepare for Accessibility workflow in many PDF editors appears often in tagging instructions because it combines automatic and manual actions. That consistency helps, but it also creates a common mistake: people stop when the automatic tag tree appears. A visible tree proves only that tags exist. It doesn’t prove that the tags describe the page correctly.

By now you should have a Document root, a sensible heading hierarchy, paragraph tags for body text, and distinct structures for lists, figures, and tables. Leave detailed reading-order repairs for the next step, where you can compare the tree with the page itself.

Step 3: Fix reading order and tag images, tables, and links

Correct reading order is the heart of PDF tagging. A screen reader follows the structure you provide, not the visual path a sighted reader guesses from the page.

Open the Order or Reading Order tool in your PDF editor. Show the numbered regions on the page. Compare the numbers with the way a person should read the content. On a two-column page, the first column should usually finish before the second begins. A title should come before the paragraph it introduces. A caption should stay with its figure.

Watch for repeating headers and footers. They may need artifact treatment when they add no new meaning on each page. If a footer contains a key instruction or legal note, it may need to remain available in the reading sequence.

Fix the tag tree after checking the visual order. Select a tag, then use the keyboard or the Tags pane controls to move it. After each large change, reread the page. Small shifts can affect every page when the source uses a repeated layout.

Tag images with purpose

Give each meaningful image a Figure tag and write alt text that explains its role. A chart needs its takeaway, not a list of colors. A diagram needs the relationship it shows. A decorative image should be an artifact or have empty alternate text, based on how it functions in the document.

Keep descriptions short when the image is simple. Add more detail when the image carries data that the surrounding text does not provide. Don’t repeat the full caption in the alt text if the caption already explains the same point.

Check the tag properties for alternate text. A parent tag with child tags should not receive an image description by mistake. That structure can make the child content disappear from the assistive technology reading path.

Tag tables and links

Tables need more than a grid of cells. Mark header cells as headers and connect them to the data cells where the PDF structure supports that relationship. A table that looks clear on screen may become a stream of numbers when read aloud.

Ask what each row and column means. If the answer is unclear without visual position, the table needs better headers or a short explanation near it. Avoid using a table tag for layout boxes that do not contain tabular data.

Links need link tags and usable link text. “Read more” gives little help when a user lists all links in the document. Use text that states the destination or action. Check that the link annotation sits with the matching link tag.

Use a screen reader preview when available, then test a few pages by moving through headings and links. Automated checks can find missing structure, but they can’t judge whether the order sounds natural. That is why a tagged PDF still needs a human reading pass. Our separate explanation of why a tagged PDF does not mean WCAG compliant covers this gap in more detail.

Some document-authoring exports can add another layer of trouble. Reports describe unwanted span tags under label folders in some tagged PDF bullet lists. If your PDF begins in a document-authoring application, inspect exported tags instead of assuming the source styles produced a clean structure.

By now you should have a reading order that matches the page, meaningful Figure tags, usable table headers, and link tags that a keyboard user can reach. The next step deals with the two file types that need extra care: scans and forms.

Step 4: Handle scanned pages and fillable form fields

Scanned pages need OCR before their content can be tagged well. OCR creates a text layer from the page image, but searchable text alone is not an accessible PDF. You still need headings, paragraphs, reading order, image treatment, and a check of the recognized text.

Run OCR on the scanned pages using a suitable PDF accessibility tool. Choose the language that matches the document. Review pages with skewed text, faint print, stamps, handwriting, or complex columns. OCR can mistake a character, join two columns, or place a line in the wrong spot.

After OCR, select text across several areas. Search for a word that appears on the page. Then compare the text layer with the scan. A single wrong name or number can change the meaning of a notice or form.

Run automatic tagging only after the text layer is usable. Fix the heading structure and reading order as you would for a born-digital PDF. Treat the scan as an image when it carries a photograph or diagram, but don’t treat a scanned page of text as one giant Figure.

Fillable forms need a separate review. Form fields must have clear names, useful tooltips, correct types, and a logical tab order. A visible label and a field can look close on screen while remaining poorly connected for a screen reader.

Use the form-preparation tool to detect fields, then inspect every field. Edit the tooltip so it matches the visible label. If a field is required, say so in the tooltip or nearby instruction. A field name helps your team manage data, but the tooltip is what the screen reader user needs.

Test radio buttons, checkboxes, lists, text fields, and buttons as different controls. A radio button needs both a group meaning and a choice meaning. A button needs a clear label. Don’t add a tooltip that overrides useful button text with something vague.

Check tab order after saving and reopening the file. Press Tab through the form. The focus should move in a sensible visual order. This test catches defects that a tag-tree review can miss.

Fillable forms are the hardest PDF type to remediate. Accessibility On Demand™ handles them through the Review Modal today, where a person confirms field labels and tab order. A fully automated forms pipeline is expected in Q3 2026.

For a deeper look at fillable form accessibility and SC 4.1.2. The key point is simple: don’t trust field detection alone.

By now you should have a real text layer on scanned pages, checked OCR output, labeled fields, and a tested tab sequence. Keep the original scan available for comparison. OCR errors are much easier to find when the source image is one click away.

Step 5: Validate the PDF, then choose a workflow for volume

Validation closes the gap that many tagging checklists leave open. Tagging is necessary. It is not the final test.

Start with a desktop PDF editor’s Accessibility Checker. Fix clear failures, then run it again. Set the file as a tagged PDF before checking. Keep the report with the finished file so your team can show what was tested and when.

Next, run a dedicated PDF Accessibility Checker when your workflow supports it. This type of checker is maintained by an industry standards organization and offered through a public information page. Automated checks cover machine-verifiable PDF/UA and WCAG requirements, while sequence, meaning, and alt-text quality still need human review.

A checker score is computed, not asserted: checks passed divided by checks run, per standard. Treat it as the floor, not the proof. Fix the source problem. Then test again.

Use a second validator when the document is important or the result is disputed. An open-source PDF/UA validator can work across operating systems. Validators can interpret some conditions differently, so a result from one checker and a second check can reveal issues worth reviewing.

Finish with a human test. Open the PDF in a screen reader. Move by heading. Move by link. Read a table. Find the figure description. Tab through every form field. Ask someone who did not tag the file to complete a normal task, such as finding a deadline or submitting a form.

Now choose the workflow that matches your volume. A desktop PDF editor remains a good fit for a small number of complex files when a trained operator needs direct control. The cost is staff time, and each document remains a hands-on job.

Manual remediation from specialist providers typically runs $5–$25+ per page. Complex fillable forms can reach $100+; remediation of a complex page commonly runs 15 to 30+ minutes, so a large archive can become a labor plan before it becomes an accessibility plan.

For large backlogs, Accessibility On Demand™ uses deterministic processing for structural work with a correct answer, such as tags, reading order, and table markup. That processing behaves the same on page 4 and page 400,000. Generative AI is used only where judgment is needed, such as drafting alt text, and the result can be checked in the Review Modal.

We publish three service levels. Standard (Level 1) costs $0.30/page and includes OCR on scans, automated tagging, logical reading order, basic image alt text, and a Compliance Score Certificate on every document. Enhanced (Level 2) costs $1.80/page and adds contextual alt text, advanced form-field tagging, and configurable bookmarks.

Level 2 (Enhanced) targets a 95%+ WCAG 2.1 AA Compliance Score, verified by the PAC (Axes4) checker. If a document doesn’t clear 95%, you’re not charged for it, with rare source-document exceptions. Expert Review (Level 3) costs $12/page and targets a 99% Compliance Score, verified by the PAC (Axes4) checker, with full WCAG 2.1 AA plus PDF/UA and human review.

Our current production benchmark is 97%+ average compliance scores across production volume, verified through the Axes4 PAC Checker API. We processed 600,000 pages in May 2026, including a 50,000-page single-day run for one customer. Those figures describe throughput and scored output. They do not mean every file reaches 100%.

The honest limit is fit. We’re not a desktop editor or an SDK that you run on your own infrastructure. We’re also not the right choice for a handful of PDFs each year, where a trained operator with a desktop editor may cost less. Remediation changes semantic structure. It does not redesign contrast, fonts, or layout.

FAQ

Can I tag a PDF without Acrobat?

Yes, you can tag a PDF without a particular commercial editor by using another PDF editor, a remediation service, or a developer tool. The method must still produce a logical tag tree, correct reading order, useful alt text, and valid table and form structure. Run a validator afterward because the presence of tags alone does not prove accessibility.

What is the fastest way to tag a PDF?

The fastest way to tag a PDF depends on its size and layout. Automatic tagging can give you a first pass for a simple file. A large set of mixed PDFs needs an automated remediation workflow followed by review and validation. Scanned pages and forms take more care because OCR and field labels need separate checks.

Does a tagged PDF meet WCAG?

A tagged PDF does not automatically meet WCAG. Tags provide structure, but the file may still have a bad reading order, missing alt text, weak table markup, unlabeled fields, or poor contrast. Run a PDF accessibility checker and an independent validation tool, then complete a human screen-reader and keyboard test.

How do I check if a PDF is accessible?

Check a PDF with a built-in or standalone accessibility checker and an independent validation tool, then inspect it with a screen reader. Automated tools can find many machine-checkable failures. They can’t decide if alt text explains an image or if the reading order makes sense. Test headings, links, tables, images, and form controls by hand.

How do I tag a scanned PDF?

To tag a scanned PDF, run OCR first and review the recognized text against the page image. Then add the tag tree, correct reading order, describe meaningful images, and validate the result. OCR makes text searchable, but it does not by itself make the document accessible.

Conclusion

For a few files, tag them in Acrobat and give every page a human review after the automated check. For a large backlog, use a workflow that combines structure, review, and automated PDF/UA validation. If you want to test that approach, the Accessibility On Demand™ free trial covers your first 100 pages.