Daily PDF/UA tips on LinkedIn
CurbEffect posts daily document remediation tips on LinkedIn, grounded directly in ISO 14289-1 (PDF/UA-1) — practical guidance for the people doing the work, not marketing fluff.
Follow CurbEffect on LinkedInWhy Accessible Documents Matter
Roughly one in four U.S. adults lives with a disability that affects how they read, navigate, or interact with digital content — yet the vast majority of PDFs published online still aren't built to work with screen readers, magnification, or keyboard navigation. For a person using assistive technology, an inaccessible PDF isn't a minor inconvenience; it's a closed door on a bill they need to pay, a meeting they want to attend, or a public record they have every right to read.
Explore the Topics
Pick a topic — each tab dives into one slice of the PDF-accessibility landscape.
Who Inaccessible PDFs Shut Out
"Accessibility" isn't a single requirement — it's a set of needs across very different ways of reading. A document that works for one group may still fail another.
Visual
Users who are blind, have low vision, or are colorblind rely on screen readers, screen magnification, or high-contrast settings. A PDF that's just an image of text, or that uses color alone to convey meaning, is effectively invisible to them.
Auditory
Users who are deaf or hard of hearing need captions and transcripts for any audio or video embedded in a document. Multimedia without text alternatives is content delivered only to people who can hear it.
Cognitive
Users with cognitive or learning disabilities benefit from clear structure, predictable layouts, and plain language. Dense legal prose with no heading hierarchy is hard for everyone — and disproportionately hard for these readers.
Motor
Users who can't operate a mouse — because of tremors, paralysis, or limb difference — navigate by keyboard or switch device. PDFs need a logical tab order, focusable form fields, and proper link targets to be usable this way.
Document Accessibility Isn't Web Accessibility
WCAG was written for the web. PDFs aren't web pages — they're self-contained documents with their own structure, their own assistive-technology behavior, and their own ISO standard (PDF/UA, ISO 14289-1). Treating a PDF like a web page leaves real gaps; treating it like a print artifact leaves bigger ones. Genuine PDF accessibility requires both perspectives at once.
WCAG
The Web Content Accessibility Guidelines define what accessible digital content looks like: color contrast, captions, keyboard operability, plain language. WCAG is the lens — but it doesn't tell you how to encode any of it inside a PDF.
PDF/UA
PDF/UA (ISO 14289-1) is the structural standard for accessible PDFs — the tag tree, reading order, semantic roles, and metadata that let a screen reader actually navigate the file. It defines how accessibility is encoded.
WCAG2ICT
WCAG2ICT is the bridge: guidance on applying WCAG's principles to non-web content like PDFs. It's how you reconcile "use sufficient color contrast" with "tag the document to PDF/UA" — together, they cover what either alone leaves out.
In short: a truly accessible PDF needs PDF/UA for its structure and WCAG (via WCAG2ICT) for its content. Skipping either one leaves a real-world barrier in place.
The Four WCAG Principles, Applied to PDFs
WCAG organizes accessibility around four principles, often shortened to POUR: Perceivable, Operable, Understandable, Robust. Here's what each one means when the document in question is a PDF.
Perceivable
Every piece of content has to be available to at least one of a user's senses. In practice: meaningful alt text on images, tables tagged so column and row headers are announced, sufficient color contrast between text and background, and no meaning carried by color alone.
Operable
A user has to be able to move through the document with whatever input they use. In practice: a logical reading order that matches the visual layout, a sensible tab order through form fields and links, bookmarks for longer documents, and link text that makes sense out of context.
Understandable
Content has to make sense, and the document has to behave consistently. In practice: the document's primary language is declared so screen readers pronounce it correctly, headings actually mark headings, form fields are labeled and instructions are clear, and statutory language is presented with structure rather than as a wall of prose.
Robust
The document has to keep working as assistive technology evolves. In practice: standards-conformant tagging (PDF/UA-1), proper document metadata (title, language, role), and a clean tag tree that current and future screen readers can parse — not a one-off hack that breaks the next time JAWS or NVDA updates.
Where PDF/UA and WCAG Diverge
PDF/UA covers structure. WCAG covers content. They overlap heavily, but each one covers ground the other doesn't — which is why claiming "PDF/UA compliant" isn't the same thing as claiming "accessible."
Color contrast
WCAG sets specific contrast ratios (4.5:1 for normal text). PDF/UA is silent on contrast. A PDF can be fully PDF/UA-conformant and still fail WCAG because of low-contrast text.
Captions & transcripts
WCAG requires captions and transcripts for embedded audio and video. PDF/UA doesn't address media alternatives directly. Multimedia in a PDF needs WCAG-style treatment to be genuinely accessible.
Form errors & instructions
WCAG requires that form errors be identified and that instructions be clear. PDF/UA covers form field tagging but not the error-handling experience. An accessible form needs both.
Plain language
WCAG (at AAA level) addresses reading level and plain-language presentation. PDF/UA doesn't. A perfectly tagged document written in dense legalese still leaves cognitive-disability users behind.
Practical Steps Toward Accessible PDFs
There's no single button to press — but the path is well-defined. Whether you're starting from a back catalog of old PDFs or trying to keep new ones compliant going forward, these are the steps that move the needle.
Audit what you already publish
Run your existing PDFs through an independent validator like veraPDF to see where they stand against PDF/UA-1. The report won't catch everything WCAG cares about, but it will show you the structural baseline and help you triage what needs work most urgently.
Fix the source, not just the output
Wherever possible, build accessibility into the document at the point of creation — headings styled as headings in Word, alt text on images, real tables instead of layout grids. Remediating the source is faster and more durable than remediating every generated PDF after the fact.
Build a remediation pipeline for what you can't fix at source
For documents that come out of legacy systems you can't change — utility bills, legislative output, generated notices — you need a pipeline that intercepts the PDF and applies correct structure on the way out. Generic auto-taggers don't get there; document-aware tagging does.
Validate independently, every time
Don't rely on a vendor's "compliance certificate" — rely on independent, open-standard validation. Every PDF should ship with a veraPDF report (or equivalent) so your legal, procurement, and accessibility teams have a documented audit trail, not a marketing claim.
Train the people creating the documents
Long term, accessibility lives or dies on author habits. Train your communications, legal, and program staff on how to use heading styles, write alt text, and structure tables — so the next generation of documents starts accessible, instead of needing remediation after publication.
The Legal Landscape
PDF accessibility isn't just a best practice — for most public-sector organizations, and a growing number of private ones, it's a legal requirement. The specific obligations depend on jurisdiction, but the direction of travel is the same everywhere: documents have to work for everyone.
ADA Title II (United States)
The 2024 DOJ rule under ADA Title II requires state and local governments to conform their digital content — including PDFs — to WCAG 2.1 Level AA. Compliance deadlines are tiered by population size and have been adjusted, but the rule itself is on the books.
Section 508 (U.S. federal)
Section 508 of the Rehabilitation Act requires that information and communication technology procured, developed, or used by U.S. federal agencies be accessible — measured against WCAG 2.0 Level AA, with PDFs explicitly in scope.
European Accessibility Act
The EAA took effect in June 2025 and reaches private-sector organizations selling certain products and services in the EU — including digital documents like e-books, e-commerce content, and consumer-facing PDFs.
Accessible Canada Act & AODA
Canada's ACA sets a federal accessibility framework, and Ontario's AODA imposes specific WCAG 2.0 Level AA requirements on a broad set of organizations. Other provinces are moving in the same direction.
The cost of non-compliance isn't only fines and lawsuits — it's also lost contracts, blocked procurements, and the reputational damage of being publicly identified as an organization whose documents don't work for disabled users.
Not sure where your PDFs stand?
CurbEffect helps state and local governments move from "we publish PDFs" to "we publish PDFs that work for everyone" — without rebuilding the systems that produce them. Start with a conversation about what you publish today and where your gaps are.
Schedule a 30-minute conversation