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.
This write-up covers two rounds. The first reached a clean Acrobat check. The second came after I had the published file audited at the tag level and found problems that both Acrobat and my first screen reader pass had missed. I corrected them, and I describe both rounds because the second one changed what I would claim about the first.
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 2026 (PDF Accessibility Checker, version 26.1), for PDF/UA conformance validation.
- NVDA, for screen reader verification of reading order and alternative text.
- pikepdf and qpdf, command-line PDF libraries used for the second-round tag repairs. Claude, an AI assistant, wrote and ran those scripts at my direction. I ran Acrobat and PAC myself and reviewed the results.
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.
Second pass: auditing the tag structure
After the sample was published, I had the file's tag tree inspected directly, rather than relying on checker summaries. That found several defects that no automated check reports.
- Table 1 was not one table. It was split into two tables. Several data rows were tagged as figures carrying the chart alternative text, and the birth-year rows were tagged as artifacts, so a screen reader skipped or mislabeled them. I rebuilt it as a single table with a caption, one header row with column scope, row headers with row scope, and group rows that span all three columns.
- Confidence intervals read as negative numbers. The source text has no space after the hyphen, so a range like 4.2 to 7.1 could be announced as "4.2 minus 7.1". I added reading text so each range is announced as "4.2 to 7.1".
- The real charts were hidden. Both charts were tagged as artifacts, while the alternative text sat on the table rows. I tagged each chart as a figure with its alternative text, and corrected the first one, which called a line chart a bar chart.
- Hidden numbers. The weighted percents for the 2017 to 2022 rows were in the file, but a later shading box painted over them, so sighted readers saw blank cells while screen readers read the values. I redrew them on top.
- Housekeeping. Page numbers became artifacts. Seven empty form fields were removed. Duplicate and orphaned link annotations were removed, and the remaining links got descriptive contents. The footnotes were flattened from Note tags into their paragraphs. The root tag changed from Part to Document, and I added bookmarks from the headings.
- Fonts. The body text fonts, Arial and Times-Roman, were not embedded. (The chart labels already carried an embedded Arial subset, which I left as it was.) I embedded Liberation Sans and Liberation Serif, open-license fonts with the same character widths, so the layout did not change. The letter shapes differ slightly from Arial.
- The identifier, last. Only after the structure was repaired did I add the PDF/UA identifier to the file's metadata.
Result of the second pass
Acrobat's check again reported no problems, with 28 rules passed and reading order and color contrast left as manual checks. PAC's report on the final file says the PDF/UA requirements it checks are fulfilled, with no failures and no warnings in any checkpoint. The report is linked below.
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 | One table, headers with scope |
| PAC failed checkpoints | Hundreds | 29 (after first pass) | 0 |
| Fonts | Not reported | Not embedded | Embedded |
| 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 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. The second pass went one step further: PAC and Acrobat both count tags, but neither checks that the right content is inside them, so I also inspected the tag tree directly.
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 are substitutes: the original body text fonts were not embedded, and I did not have the licensed Arial files to embed. Liberation Sans and Liberation Serif have the same character widths, so the layout and text are unchanged, but the letter shapes differ slightly from Arial. Regenerating the file from the source with Arial embedded would remove that difference.
- Missing values in Table 1: the two WIC rows have no weighted percent in the table, while Figure 2 labels them 9.4% and 9.6%. I left the table as published and flagged the gap, because I cannot confirm those values against the source report.
- Manual checks remain manual: Acrobat cannot judge reading order or the color contrast of chart graphics, so those depend on the screen reader pass and a visual check.
- Role mapping and structure elements: the failures PAC reported in the first round came from custom tag types and from content tagged as the wrong element. They were resolved in the second pass.
- PDF/UA identifier, added last: I withheld the identifier in the first round because the file did not yet conform, and stamping a conformance claim onto a non-conformant file would be improper. I added it only after the structure was repaired and the file had been validated in PAC.
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. In the first round I could not reach the detailed failures I needed to target individual structure fixes. In the second round I had Claude open the detailed results on my computer, read each warning, and save them to a text file, which is how I learned about the root tag and bookmark issues.
- 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.
The second pass showed the limits of that test. The charts announced their alternative text in the first round, but the text was attached to table rows, not to the charts, and neither my ear nor the checkers could tell the difference. Listening and inspecting the tag tree catch different problems, and a sound remediation needs both.
I repeated the screen reader pass on the final file before publishing it.
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.
- Auditing my own published work at the tag level, finding defects the checkers and my first screen reader pass missed, and correcting them in the open.
- Distinguishing what document remediation can fix from source-level limitations, and declining to assert conformance until it was earned.