The issue of the “text worm” PDF proves that compliance isn’t always accessibility when it comes to digital documents. These files may pass PDF/UA checks, but without proper structure or semantic tags, they fail to deliver a usable experience for people who rely on assistive technology.
What Is a “Text Worm” PDF?
A Text Worm PDF is a document that appears to be accessible. The document is tagged. It passes PDF/UA checks. It contains no critical errors when tested with many accessibility tools. But for someone using assistive technology, it is difficult to navigate, hard to understand, and often unusable.
These documents are filled with paragraph tags and nothing else. There are no heading tags, and no table or list tags. Likewise, there are no sections or landmarks. As a result, the content becomes a long, unbroken string of words. There is no way to move between topics. Without structure, there is no clear flow. It reads as a continuous block of information. Now imagine the user experience if you knew this was an important document, and you had to make a life-impacting decision based on what it contained.
This is the Text Worm. It passes basic compliance. But it fails the user who needs structure and context to make sense of the content.
Unequal Experience for Non-Sighted Users
A sighted user can glance at a PDF and see clear structure. For example, headings stand out visually, sections are spaced apart, tables are aligned, and lists have bullets or numbers. It looks easy to navigate.
But a screen reader can’t see any of that. It relies entirely on tags to understand structure. If everything is tagged as a paragraph, there are no headings to skip to, no lists, no tables, and no landmarks.
The sighted user can scan and jump between sections. In contrast, the non-sighted user is forced to listen to every word in order. That isn’t equal access. It isn’t accessibility.

Imagine receiving a document that looked like this. Would you be able to make an important decision? Would you know if any action was required?

Now, imaging receiving this document. It is the same document as the previous one but it is properly and logically organized. You can quickly see that you need to pay a Credit Card bill.
When it comes to digital documents, a text worm PDF highlights the gap between compliance and accessibility, exposing how surface-level validation can still result in a poor user experience.
Encountering a Text Worm
For a screen reader user, opening a text worm PDF is frustrating from the start. Navigation by heading does not work. The heading list is empty. Tables are not tagged. As a result, there is no way to move through the document efficiently.
The user begins reading from the top. What follows is a continuous stream of content with no breaks, no section cues, and no structure. Consequently, there is no way to skip ahead or return to important points. Every word must be heard in sequence.
As a result, this experience is not just inconvenient. It is exhausting. A tagged document without structure is not accessible.
Why the Text Worm Exists
Text worms are often the result of automation with incorrect set-up. Specifically, document generation systems produce high-volume content like invoices, insurance policies, contracts, and reports. These systems often apply basic tags, wrapping everything in paragraph tags without adding headings, lists, tables, or logical reading order.
Some composition software even claims to output accessible PDFs, but the results often lack proper structure. This happens because the goal is often speed and volume, not usability. Automation replaces structure with shortcuts. The result is a document that looks good to sighted users but leaves non-sighted users behind. Many assume that if a screen reader can read the text aloud and the file passes the compliance checker, the document is good enough. It is not.
Passing a Checker Is Not Enough
Accessibility tools can confirm that a tag tree exists. They can check for alt text, document language, and title. They can mark a document as technically compliant. But they cannot judge the experience of reading that document with a screen reader.
This is where many organizations fall short. They trust the tools. They follow the checklist. But they never test the outcome. They never hear what a non-sighted user hears. They never compare the experience side by side.
A document that passes a validator but delivers no meaning, no navigation, and no context is not accessible. It may meet the letter of PDF/UA. But it does not meet the goals of WCAG, AODA, ADA, or Section 508. It does not serve the user.
A text worm PDF may meet compliance on paper, but when it comes to digital documents, real accessibility depends on how well the structure supports actual navigation and understanding.
Truly Accessible PDF
A compliant PDF/UA is not always an accessible PDF/UA. In order to be truly accessible, a document must be structured properly. It must help users understand, navigate, and locate information efficiently.
Heading Tags
- Headings break the content into clear sections.
- They help users move through the document.
- They show the hierarchy of ideas.
- Use H1 for the main title, then H2, H3, and so on.
List Tags
- Tag bullet points and numbered items as lists.
- This allows screen readers to announce how many items are present.
- It helps users follow grouped ideas.
Table Tags
- Tables must include headers, rows, and cells.
- Set the relationship scopes.
- Use semantic tags like Table, TR, TH, and TD with proper relationships.
- This helps the user understand relationships in the data.
Alt Text or Artifact Images
Add clear, descriptive alt text to all meaningful images so screen readers can convey their purpose. For decorative or redundant images, mark them as artifacts to keep them from interrupting the reading experience. This ensures users only hear what matters and are not distracted by non-essential content.
Other Tags
There are a wide range of tags available in PDF accessibility, each with a specific role. Therefore, all meaningful content should be tagged (if it isn’t tagged, it won’t be read), and the correct tag must be used to reflect its purpose. This ensures that assistive technology can interpret and present the document clearly.
Correct Reading Order
Ensure that the content reads in logical flow.
Test for order issues with sidebars, columns, and footers.
A broken order can confuse even well-tagged content.
For more information about Reading Order, refer to CDP Blog article: Reading Order Matters in Digital Documents – CDP Communications Inc.
Identify a Text Worm PDF
To check if your process is producing text worms, start by selecting a sample set of typical documents. Then, process them through your PDF generation or remediation software and validate the results using a PDF/UA compliance checker.
Next, open the PDFs in a tagging tool and review the tag tree. Compare the structure to the visual layout. There should be appropriate tags that reflect the document’s sections, such as headings, tables, and lists. If everything is tagged as a paragraph, The document will lack structure.
Next, make sure all meaningful content is tagged and the reading order follows a logical flow. Finally, test the document with a screen reader. The experience should match what a sighted user sees. If the structure is missing or navigation is difficult, the document is not accessible.
Prevent Text Worms
To prevent text worms, you should configure the automation to apply meaningful tags. Specifically, this includes identifying headings, lists, tables, and images, and ensuring the correct reading order. Relying on default or paragraph-only tagging is not enough.
Automated remediation tools help improve structure after PDF generation, but only when you configure them to recognize and apply the correct tags based on content and layout. Therefore, always review the output to ensure the tagging matches the actual structure of the document.
Avoid text worms and ensure that your automation process creates properly tagged PDFs from the beginning. When tagging is accurate, consistent, and based on content structure, the result is both compliant and accessible.
In Conclusion
The issue of the text worm PDF proves that compliance isn’t always accessibility when it comes to digital documents. As a result of poorly configured automation, text worms can appear in high-volume document workflows where the process fails to apply meaningful structure. These PDFs appear in statements, policies, reports, and other content across industries, and often contain essential information. When that structure is missing, non-sighted users receive a disconnected stream of content with no way to navigate, while sighted users can quickly scan and understand. The experience is not equal. Real accessibility means every user can find, understand, and navigate content with the same confidence. That requires tagging that reflects meaning and structure, not just compliance.
ADEPT UA solves this by using rule-based automation to apply proper semantic tags without relying on rigid templates. It ensures the process builds every document for accessibility from the start and tests it against the expectations of real users. So, avoid the text worm. Build documents that work for everyone.