Sample deliverable

Every remediation I deliver comes with a report like this one. It states what was corrected, what was found and deliberately left alone, and what a checker still objects to. A finding you were not told about is the only kind that should worry you.

This is the real report for the four-language case study on the multilingual PDF accessibility page. Nothing in it has been softened for publication.

Know Your Rights: Workplace Discrimination is Illegal — U.S. Equal Employment Opportunity Commission poster, four language editions: English, Spanish, Arabic and Simplified Chinese. Source files downloaded from eeoc.gov on 22 September 2026. Works of the U.S. federal government, public domain.

Standard: PDF/UA (ISO 14289-1). Verifier: PAC 2026 (axes4). Result, all four files: the PDF/UA requirements checked by PAC are fulfilled — all ten checkpoints pass with zero warnings and zero failures.

The drop in structure-element count is not a loss of content: the source files wrapped text in long chains of redundant elements. Text content was compared character by character before and after every processing step.

Both files carried he in the document catalog. A screen reader trusts that declaration and selects a Hebrew voice, so both documents were unusable to the readers they were translated for. No visual inspection reveals this; it is a single entry in the file.

In the content stream the words run in the order they are painted on the page, not the order they are read. Copy the text out and it comes back scrambled; a screen reader receives it the same way. ISO 32000-1 §14.8.2.3.3 describes how such text is to be marked. 95 block elements were given /ActualText holding the correct logical-order text, including lam-alef ligatures and the Latin runs — URLs, “EEOC”, phone numbers — embedded inside right-to-left lines, which keep their own direction.

PAC does not check this. A file can pass PDF/UA with its Arabic text stored backwards.

In all four source files, six /Link structure elements referenced the link annotation but did not enclose the visible text — the text sat in a sibling paragraph while the element holding the link contained nothing but empty spans. A screen reader reading the portal address was therefore never told it was a link.

Corrected by splitting the marked-content sequence at the boundaries of the link text and placing that part inside the /Link element, in the correct reading position. No glyph, kerning value or position changed. Six of six corrected in English, Spanish and Chinese; four of six in Arabic, for the reason in 2.3.

Measured 4.35:1 — #ED1F24 red on white at 9–10 pt, against the 4.5:1 required by WCAG 2.2 AA for normal text. It affects the four contact labels and is the EEOC’s own brand red, identical in the source files.

Not changed, because changing it is a design decision, not a remediation decision. Altering an organisation’s brand colour without authorisation is outside the scope of accessibility remediation. The measurement is provided so the decision can be made by whoever owns the design.

The TTY line reads 1-800-669-682 in the Arabic file — one digit short of the 1-800-669-6820 printed in the other three. It is the number for readers who are deaf or hard of hearing, so in the Arabic edition the one group of readers that number exists for cannot reach it.

Not changed, because correcting published content requires the publisher’s decision. For the same reason it was not turned into a dialable link: linking an invalid number would conceal the defect rather than surface it. No validator reports this; it was found by comparing the four editions against each other.

Two links on page 2 sit inside a paragraph whose /ActualText covers several marked-content sequences at once. Splitting it would have destroyed the logical text of the other content in the same element — the URL would have been read twice, once correctly and once character-reversed.

Not changed, because reading order is worth more than a checker item. The reading text produced by walking the structure tree is byte-for-byte identical to the text before this work, in all four files.

These go slightly further than restoring the document’s existing meaning, so they are listed rather than passed over in silence. Either can be reverted on request.

• Telephone numbers made dialable — 5 in English, 5 in Spanish, 5 in Chinese, 4 in Arabic. The source files had no such links. Nothing changes visually.
• Bookmarks generated from the heading structure — 15 per file. The source files had none.

Link descriptions were rewritten. They originally read as raw addresses — a screen reader announces a long portal URL character by character. All 24 were replaced with descriptions of the destination in the document’s own language. A checker accepts a raw URL as a valid description; a person listening to it does not.

Every page was rendered at 120 dpi and compared pixel by pixel against the source.

Every scripted step measures zero pixel difference. The figures above come from one save performed by Adobe Acrobat during the manual tagging stage, which re-embeds fonts. Those pixels were inspected at 350–400 dpi: they are edge-smoothing differences along glyph outlines and one underline. The figures are reported rather than described as “unchanged”, because they are not zero and anyone can measure them.

PAC 2026 has four tabs, and its exported PDF report covers only the PDF/UA tab. The other three were read from the application itself.

The only failing WCAG criterion in any file is 1.4 Distinguishable — the contrast measured in 2.1. Every other criterion passes or does not apply.

The Chinese file’s remaining link finding could not be reproduced. PAC points at the portal URL on page 1, but in the file that URL is inside its /Link element with the correct content, and the same construction passes in the English and Spanish files. Six readings of PAC’s criterion were tested against the file; none reproduced its result. Adobe Acrobat’s own accessibility check was run on the same file as a second opinion and reports no failures at all — including its “Tagged annotations” rule, which is the one covering link tagging. The finding is recorded here rather than explained away.

Whitespace warnings are a PAC quality hint, not a conformance requirement; Acrobat’s checker has no equivalent rule and the source files carry the same warnings. The count rose by exactly one per element split while wrapping link text. The unit PAC counts could not be reproduced, so the increase is reported rather than described as harmless.

• The verifier result covers what PAC 2026 checks. PDF/UA conformance in full includes requirements no software can decide — whether a heading level reflects the document’s actual structure, whether an alternative text describes what the image conveys.
• Adobe Acrobat was used only to read the files. Nothing was saved through it: an earlier re-save by Acrobat reduced /ActualText coverage and broke PDF/UA conformance, so every change in this delivery was made by script and verified.
• The documents were not tested with a screen reader. Statements about how assistive technology would treat the files are derived from the file structure and the PDF specification.
• Text content was verified character by character after every step. No text was added, removed or reordered on the page.
• Colour contrast was measured programmatically from the rendered pages against WCAG 2.2 thresholds.

Every claim above is in a file you can download. The verification reports are PAC’s own output.

In the Arabic and Chinese reports the document title renders as empty boxes: PAC’s report template uses a typeface that has no glyphs for those scripts. The title is present in the file — select that line in the report and copy it to see the text.

Back to multilingual PDF accessibility · Barrierefreie PDF (Deutsch) · Erişilebilir PDF (Türkçe)