Document Accessibility Remediation
Tagged PDFs, verified by structure — to the standard your rulebook names
State and local government entities face fixed deadlines for accessible web content and documents. Under the U.S. Department of Justice's ADA title II rule, as revised by its April 2026 interim final rule, the compliance date is April 26, 2027 for entities with a total population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments.
The harder part is that "accessible" is not one target. The federal rule names WCAG 2.1 Level AA and pins the 2018 version of it. Minnesota's own standard names WCAG 2.1 Level AA together with Section 508. Washington's statewide document-accessibility contract names WCAG 2.2 Level AA and, for PDFs, PDF/UA — ISO 14289 — and rolls forward automatically as those standards are updated. A vendor who answers with a single version number is answering a different question than the one your contract asks.
We remediate document sets to the standard that governs your work: structure and reading order, heading hierarchy, table headers, alternate text, form field labels and document metadata, plus plain-language rewriting where the obligation is comprehension and not just markup. Drafting is AI-assisted and every result is human-reviewed and human-approved before it ships — the same shape as the rest of our work.
Direct Procurement Contact
Ryan Newbloom, President
The Standard We Build To
- Federal — ADA title II: WCAG 2.1 Level AA, as the rule specifies it (the 2018 W3C Recommendation)
- Minnesota — the State Accessibility Standard: WCAG 2.1 Level AA with Section 508
- Washington and PDF-specific contracts: WCAG 2.2 Level AA plus PDF/UA (ISO 14289-1 or 14289-2)
- Contracts with a rolling-update clause: the current standard your policy authority has adopted, not the one in force at bid time
- Where your rulebook names something else, we build to that — and we ask which one before quoting
How We Verify — Structure, Not Appearance
- Tagged-document structure present and marked (/StructTreeRoot, /MarkInfo)
- Document language set, and the title shown in place of the filename
- Heading hierarchy and navigable bookmarks
- A non-zero header-cell count in every single table
- Text layer intact — never rasterized, which silently destroys both tags and searchability
- Checks run programmatically on every export, on every rebuild
Why we verify structure instead of reviewing renders
An evaluator scoring an accessibility factor may well run a checker on the document you hand them. So do we — before they do, and on every rebuild rather than once at the end.
This is not a theoretical preference. Building our own accessible document packages, automated structure checks caught two defects that no visual review would have found: a word processor that silently declined to mark table header rows unless the table explicitly declared its first row as a header, and an export setting that rasterized text into images — destroying the tag tree and the text layer together — while producing a file that looked flawless.
A clean render is not evidence of clean structure. Treating it as evidence is how document sets get delivered, accepted, and then fail the first time somebody actually uses a screen reader on them.
Questions Buyers Actually Ask
It depends on who is buying and under what authority. The ADA title II rule names WCAG 2.1 Level AA for state and local government web content and mobile apps. A state accessibility standard may name the same version alongside Section 508. A statewide document-accessibility contract may name WCAG 2.2 Level AA plus PDF/UA and update itself as those standards change. We establish which one governs before scoping, because it changes the work and the acceptance criteria.
No, and this is the most common and most expensive assumption in document remediation. Accessibility lives in the document's tag tree, not its appearance. A visually perfect PDF can have no structure tags at all, no reading order, no table header cells, and no document language — and a screen reader will present it as an unnavigable wall of text. That is why we verify structure programmatically rather than reviewing renders.
Defects that a clean-looking render hides completely. Two real examples from our own build pipeline: a word processor's header-row inference is not stable unless the table explicitly declares its first row as a header, so tables that look correct can export with zero header cells; and one common PDF export setting rasterizes any text whose font is unavailable, which destroys the structure tags and the text layer at the same time while producing a document that looks perfect on screen. Both were caught by automated checks, not by inspection.
Yes, and they are separate obligations that are often confused. Markup conformance makes a document navigable by assistive technology. Plain language makes it comprehensible to the person reading it. A form can be fully WCAG conformant and still be unusable by the population it was written for. Where a document set exists to be understood — public notices, benefit forms, participant instructions — we treat the rewriting as part of the deliverable.
Where a solicitation or contract requires signed third-party accessibility validation, we scope an independent accessibility specialist into the engagement rather than self-certifying the result. Tell us what your acceptance criteria require and we will state in writing how it will be satisfied.
By the document set, not by the page. Scoping starts with a sample: we take a representative handful of your documents, run the verification checks against them as they stand, and report what is actually wrong. That report tells you the size of the problem in your own inventory before you commit to remediating all of it, and it is the basis for a fixed scope.
Ready to talk?
Direct line to Ryan Newbloom. No forms to fill out — call or email and you'll hear back within one business day.