Every character must map to Unicode

PDF/UA check CHARACTER_UNICODE · Fonts & text encoding · severity Critical · PDF/UA 8.4.5.8 Unicode character maps

↩ Back to the rules index · WCAG cross-reference

Why it matters#

Each character must have a Unicode value so screen readers can pronounce it. Without proper mapping, text might appear visually correct but be read as gibberish or skipped entirely by assistive technology.

What you will see#

Text renders correctly on screen but has no reliable Unicode mapping, so copying it out or reading it aloud produces nonsense.

How to fix#

Add a ToUnicode CMap entry to each flagged font dictionary that maps every referenced character code to its correct Unicode value. Re-exporting the PDF from the source application with proper font embedding usually regenerates valid mappings; otherwise re-embed the fonts with a tool that builds the ToUnicode CMap.

Step-by-step guide#

1. Identify both failure prongs from the EQChecker report: fonts whose dictionary lacks a ToUnicode entry, and pages where decoded real-content text yields U+FFFD, U+0000, U+FFFE, or U+FFFF (glyphs with no usable Unicode value).
2. Preferred fix: re-export the PDF from the source application - modern exporters embed fonts with correct ToUnicode CMaps, which resolves both prongs at once.
3. Know the two pass paths: a font either carries a ToUnicode CMap mapping every referenced character code to a valid Unicode value, or it qualifies for an exemption in PDF/UA-2 8.4.5.8 - see notes. If the font legitimately qualifies, no CMap is needed; otherwise add one.
4. If the flagged text is an invisible OCR layer (text rendering mode 3), re-run OCR with a current engine (Acrobat: All tools > Scan & OCR > Recognize text) to regenerate the text layer with valid mappings - invisible text is still checked because it is exactly what assistive technology reads.
5. Otherwise the font was embedded without usable Unicode mappings by its producing application. Acrobat has no menu or Preflight fixup that creates ToUnicode CMaps, so the only reliable fix is regenerating the file from its source with an export pipeline that embeds fonts with correct ToUnicode CMaps.
6. Ensure no mapping resolves to 0, U+FEFF, or U+FFFE, and map Private Use Area codepoints only when no valid Unicode value exists - such content also needs ActualText or Alt per 8.4.3.

Verify: Re-run the EQChecker scan: both prongs of CHARACTER_UNICODE should pass (all fonts have or are exempt from ToUnicode, and no decoded text contains replacement characters). Acrobat's Check for accessibility should pass Character encoding.

Note: 8.4.5.8 exempts: predefined MacRoman/MacExpert/WinAnsiEncoding; Type 1 or 3 fonts whose referenced glyph names are all in the Adobe Glyph List or Symbol set; Type 0 fonts using Adobe-GB1/CNS1/Japan1/KR-9 collections; non-symbolic TrueType. EQChecker implements only the predefined-encoding and Identity-H/V exemptions, so other fonts without ToUnicode are flagged - adding the CMap is the reliable fix. Artifact text is exempt from the character-level prong. Rendering mode 3 text is NOT exempt.

WCAG success criteria#

1.3.1 Info and Relationships — Level A#

Structure and relationships conveyed visually (headings, lists, tables, labels, groups) must also be available programmatically.

Understanding 1.3.1

Standards#

This check contributes to the following standards:

PDF/UA WCAG A EN 301 549

References#

• Matterhorn Protocol 1.1 — PDF Association