Case Study
PDF Accessibility Remediation Case Study
Remediating a section of a Kansas public health surveillance report
Overview
I remediated a representative three-page section of the Kansas Pregnancy Risk Assessment Monitoring System (PRAMS) 2022 Surveillance Report, a real public health document published by a state agency. The source file failed accessibility validation across hundreds of checkpoints. My goal was to take a representative sample to a clean Adobe Acrobat accessibility check, then validate the result against the stricter PDF/UA standard using PAC, and document honestly what could and could not be resolved through document-level remediation. I worked almost entirely by keyboard and screen reader, which shaped several of the choices below.
Source document and scope
The full report is 104 pages and is dense with statistical tables and charts. A full PAC scan of the source returned 260 structure element failures and 417 alternative description warnings, among others. Remediating all 104 pages was not the right use of effort for a portfolio sample, and scoping a representative section is standard practice for remediation work. I selected three pages chosen for variety, so the sample would demonstrate different skills rather than repeat one:
- Introduction page: prose and heading structure.
- Gestational Diabetes page: a data table with grouped row categories, plus a two-column layout that tests reading order.
- Figures page: two statistical charts that require meaningful alternative text.
Tools
- Adobe Acrobat Pro, for tagging, the Tags panel, and the built-in accessibility check.
- PAC 2024 (PDF Accessibility Checker), for PDF/UA conformance validation.
- NVDA, for screen reader verification of reading order and alternative text.
What I did
Baseline and automated first pass
I set the document language and a real title, then ran Acrobat's Autotag to generate an initial structure. Autotag took the sample from 15 accessibility failures to 4, building the table, list, and content tags. As expected, it left the judgment-dependent work for me.
Chart alternative text, authored from the data
The two charts are drawn as vector graphics, not images, so I could not rely on a visual read. I authored their alternative text from the underlying values in Table 1, which is the correct method when a chart cannot be seen. Because the full data set already exists in an adjacent accessible table, I wrote the alternative text to convey the trend and the key disparities rather than restate every value, and I pointed the reader to the table for the complete figures. Duplicating all nineteen values in an alternative text string would be harder for a screen reader user to navigate, not easier.
Correcting Autotag's mistakes
- Decorative divider: Autotag tagged a thin decorative rule as a figure. I re-tagged it as an artifact so assistive technology ignores it.
- False headings: Autotag promoted bold lines, including the table caption, to headings, which broke the heading sequence. I demoted them to paragraphs, leaving a clean hierarchy.
- Broken link: I found and removed a link annotation that pointed to no destination, a defect that affects every user.
Result of the Acrobat pass
After this work, Acrobat's accessibility check reported no problems. Every machine-checkable rule passed, with reading order and color contrast remaining as the expected manual checks.
Before and after
| Checkpoint group | Source (104 pp) | Extract before | Extract after |
|---|---|---|---|
| Tagged PDF status | Failing | Untagged | Tagged, passed |
| Acrobat failures | Not run | 15 | 0 |
| Figure alt text | 417 warnings | Missing | Authored |
| Headings | Inconsistent | Skipped levels | Clean nesting |
| Tables | Many failures | Untagged | Headers + scope set |
| Broken links | Present | 1 (empty) | Removed |
Validation: why I did not stop at Acrobat
A clean Acrobat report does not mean a document conforms to PDF/UA. To confirm, I validated the finished file in PAC, which applies the Matterhorn Protocol and is considerably stricter. PAC returned remaining failures in three areas: fonts (7), structure elements (18), and role mapping (3), plus one metadata item. Catching this gap is the point. A remediator who trusts Acrobat alone will ship files that are not actually conformant.
Known limitations and professional judgment
Not every issue can be resolved through document-level remediation, and treating the remaining items honestly matters more than forcing a perfect score.
- Fonts (source level): the font failures are embedding and character mapping problems baked into how the original PDF was generated. They were present in the source before I began. Resolving them requires regenerating the file from an accessible source, which is outside document remediation.
- Role mapping: the three role mapping items correspond to custom tag types Acrobat's Autotag introduced. They are mapped to standard types, and the structure they describe is sound.
- Structure elements: these are PDF/UA technicalities. I verified directly that the fundamentals are correct: links wrap their object references, figures carry alternative text and bounding boxes, footnotes have unique identifiers, and tables are properly nested with header cells.
- PDF/UA identifier, withheld on purpose: the single metadata failure is the missing PDF/UA identifier. I chose not to add it, because the file does not yet fully conform. Stamping a conformance claim onto a non-conformant file would be improper. The identifier belongs on a file only once it genuinely conforms.
Tool accessibility barriers
I completed this work as a screen reader user, and I ran into real accessibility barriers in the remediation tools themselves. These are worth documenting, because they affect any practitioner who relies on assistive technology, and because remediation tools that are not themselves accessible are a problem the field should name.
- Adobe Acrobat Preflight: when I tried to add the PDF/UA identifier through Preflight, my screen reader announced almost nothing as I moved through the dialog by keyboard, only a generic control and a single edit field. The fixups list and the action buttons were not reachable, so the dialog could not be operated without sight.
- PAC detailed results: PAC exports only its summary report. The specific checkpoint failures exist only inside PAC's interactive interface, which does not navigate cleanly with a screen reader. I could not reach the detailed failures I needed to target individual structure fixes, which limited how far the remaining items could be diagnosed.
- Locating a small link annotation: the broken link was roughly eight points wide, which is not practical to find visually. I removed it by entering link editing mode and using Select All to target it without relying on sight, rather than hunting for the box on screen.
Reading order, verified by screen reader
Automated checkers cannot confirm that content reads in a sensible order, so I verified the sample by ear in NVDA. This testing surfaced a problem the automated check had passed: only one section title was tagged as a heading. The second section heading had been lost during cleanup, yet Acrobat's nesting check still passed, because a single heading with no skipped levels is technically valid even though it leaves a section unnavigable. I re-tagged the section title as a heading so that heading navigation works the way a screen reader user expects. With that corrected, I confirmed the rest by screen reader. Heading navigation moves cleanly between the two sections. The data table reads and cycles in a logical order, including the two-column layout where narrative sits beside the table. Both charts announce the alternative text I authored, conveying the prevalence values and trends rather than a bare label. This is the kind of verification that automated tools cannot provide, and it is where lived assistive technology experience adds direct value.
What this demonstrates
- Scoping a large, complex document into a representative sample, the way remediation work is actually triaged.
- Authoring meaningful chart alternative text from underlying data, including the judgment to summarize rather than duplicate an accessible table.
- Correcting automated tagging errors: artifacts, heading structure, and a broken link.
- Validating against PDF/UA with PAC, not just Acrobat, and understanding the difference.
- Screen reader testing that caught a navigation failure the automated check passed, then correcting it.
- Distinguishing what document remediation can fix from source-level limitations, and declining to assert conformance that does not exist.