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:

Tools

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

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.

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.

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.

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