无障碍 PDF：标签结构、阅读顺序与发布前验证

一份 PDF 可以看起来无可挑剔，却完全无法被辅助技术使用。分栏对齐，表格有边框，标题又粗又大，屏幕阅读器却先念页码，再念侧栏，最后把一个表格单元格当成普通段落读出来。渲染出来的画面看不出任何问题，因为问题不在视觉，而在结构。

PDF 无障碍由两层标准共同定义。WCAG 规定结果：内容必须可感知、可操作、可理解、足够健壮。ISO 14289（PDF/UA）规定 PDF 要怎样构建才能达到这些结果。两层标准都不看外观。只有当逻辑结构、阅读顺序、文本替代、元数据和交互模型都正确，并且视觉设计本身可用时，这份文件才算无障碍。

下面说明结构树里到底有什么、阅读顺序从哪里来、转换会破坏什么，以及发布前如何验证。

标签化 PDF 里到底有什么

PDF 页面本质上是一条内容流。它在坐标上绘制字形，把图片画进矩形，给线条描边。格式本身没有标题、段落、列表、表格单元格这些概念。对阅读器来说，标题只是字号更大的文字；对屏幕阅读器来说，没有额外信息时它也只是文字。

标签补上了这层含义。标签化 PDF 在文档目录中加入结构树，由 /StructTreeRoot 引用，并设置 /MarkInfo << /Marked true >>。页面内容流中的一段段内容被 BDC 和 EMC 操作符包起来，携带一个标记内容标识符，也就是 MCID。结构树再指回这些 MCID，于是每一块可见内容都和一个逻辑元素关联起来，例如 /H2、/P、/LI、/TH 或 /Figure。

没有标签时，阅读器只能猜。多数屏幕阅读器会按几何位置推断：从上到下、从左到右，再做一点分栏判断。简单页面猜得还行，遇到侧栏、表单、多栏报告和表格就会出错。标签化 PDF 用明确的声明取代猜测：每个元素是什么，应该按什么顺序读。

但声明可能是错的。文件可以有标签，却把视觉上的标题念成正文，把脚注排在引用它的段落之前，漏掉替代文本，或者把一张数据表标成一堆段落。所以“标签化 PDF”和“无障碍 PDF”不是同义词。打标签是机制，无障碍是正确使用这套机制之后的结果。

真正可访问的 PDF 需要四件事同时成立：完整正确的结构树、符合逻辑的阅读顺序、能传达含义的文本替代与元数据、满足对比度和可用性要求的视觉设计。只有前两项是纯粹的标签问题。

结构树、角色映射与阅读顺序

结构树是一套层级。/StructTreeRoot 下面有 /Document，文档下面再放标题、章节、段落、列表、表格和插图。每个元素有一个 /K 条目列出子项。子项可以是另一个结构元素、指向某个 MCID 的标记内容引用、指向注释对象的对象引用，或者页面内容项。

标准角色名由 PDF 规范定义：/H1 到 /H6、/P、列表 /L、列表项 /LI、项目符号或编号 /Lbl、列表项正文 /LBody、表格 /Table、行 /TR、表头单元格 /TH、数据单元格 /TD、插图 /Figure、题注 /Caption，以及不参与阅读的 /Artifact。角色映射可以把自定义名称翻译成标准角色，但映射修不好错误的层级。如果排版工具把自定义的 HeadingLevel2 映射成 /P，这个标题即使名字看起来合理，也不会出现在屏幕阅读器的标题列表里。

阅读顺序就是结构树的深度优先顺序。屏幕阅读器不按坐标排序，而是从树根往下走，进入一个元素，读完它的内容，再移到下一个兄弟节点。如果树里侧栏排在主标题前面，用户听到的就是侧栏在前，无论它在页面上位于哪里。页眉、页码、分隔线和装饰背景属于伪影，放在阅读顺序之外，可以直接标为 Artifact，也可以放进 /Artifact 元素。

页面和结构树之间靠父级树连接。每一页有 /StructParents 键，父级树用页索引加 MCID 找到拥有这段内容的结构元素。如果复制、重排或重新生成页面时没有同步更新这些引用，可见页面和逻辑结构就会脱节。文件照样能打开，看起来也正常，但无障碍结构已经指向错误的内容。

结构树还可能是“退化”的。整份 PDF 只有一个 /Document，下面塞进几千个 /P，技术上确实有标签，却没有标题导航、没有列表语义、没有表格关系。它只是一个穿着结构树外衣的纯文本文件，而且通常保留的是绘制顺序，不是逻辑顺序。

/StructTreeRoot
  /Document
    /H1        "Accessible PDFs"
    /P
      /Span    "A tagged PDF stores a logical structure tree."
    /Figure  <</Alt (Bar chart: approval rate rises from 41% in 2021 to 78% in 2025.)>>
    /Table
      /TR
        /TH  <</Scope /Column>>  "Quarter"
        /TH  <</Scope /Column>>  "Approval"
      /TR
        /TD  "2025-Q1"
        /TD  "74%"

# 页面内容流中对应的标记内容：
/H1 <</MCID 0>> BDC
BT /F1 18 Tf 72 720 Td (Accessible PDFs) Tj ET
EMC
/P <</MCID 1>> BDC
BT /F1 11 Tf 72 690 Td (A tagged PDF stores a logical structure tree.) Tj ET
EMC

这个例子经过了简化，但对应关系是准确的：结构树命名元素，标记内容标识页面字节，父级树把两者连接起来。如果 /Figure 没有 /Alt，检查器能报出来；如果替代文本写的是“一张图表”，检查器不会报，而屏幕阅读器用户什么有用信息也得不到。

为什么视觉顺序不等于阅读顺序

一份 PDF 至少有三套顺序，它们并不是同一件事：页面绘制内容的顺序、元素在视觉上出现的顺序、结构树编码的顺序。只有第三套是辅助技术的阅读顺序，而且前提是它被打对了。

排版软件按自己方便的顺序绘制内容。报表生成器可能先把左栏每一行画完，再画右栏，因为数据就是这样送进来的；另一个生成器可能逐行横跨两栏绘制。设计工具可能先放正文，最后才画侧栏。没有标签时，屏幕阅读器只能看到成品页面，用启发式规则推断意图。有标签时，由打标签的人决定顺序，而这个决定可能朝另一个方向出错：标签完全照搬绘制顺序，即使视觉上明显应该先读正文。

文本框和浮动元素是典型失败。页面中部的一段引文可能在整篇文章画完之后才绘制，按绘制流阅读就会跑到最后；侧栏可能在它旁边的标题之前绘制，按结构读就会先读侧栏。脚注、图注和表注也一样：页面位置说明它们属于哪里，结构树却决定它们何时被读到。图注应该跟在该图之后，脚注应该跟在引用它的位置之后，而不一定是页面最后一段之后。

表格把差异放得更大。可见的网格常常由独立线条画出，单元格文字可能按行绘制、按列绘制，或者按排版引擎自己的顺序绘制。没有 /Table、/TR、/TH、/TD，屏幕阅读器听到的是一串碎片，无法说出当前单元格对应哪一列的表头。表格看起来完美，语义上却不存在。

文本提取也解决不了这个问题，因为多数提取工具根本不读结构树。它们根据字形位置和空白重建顺序。pdftotext 默认模式有自己的分栏和文本块启发式规则，pdftotext -layout 用等宽文本保留视觉布局，两者都不读标签。所以不同工具会对同一个文件给出不同顺序，而且都可能和屏幕阅读器听到的顺序不同。从 PDF 里复制文字，不能当作无障碍测试。

实际结论是：阅读顺序必须用真正消费它的技术来检查。看页面只能确认视觉正确，看结构只能确认标签声称了什么，只有屏幕阅读器能确认用户实际听到了什么。

标题、列表、表格与插图

标题是长文档的导航骨架。它们必须按逻辑层级标成 /H1 到 /H6，而不是按字号。一份文档通常应该有一个 /H1，下面是嵌套的 /H2 章节和 /H3 小节，不应跳级。加粗段落不是标题；标成 /P 的标题不会出现在屏幕阅读器的标题列表、PDF 书签或自动生成的目录里。反过来，因为“看起来醒目”就把普通段落标成 /H2，会污染大纲并误导导航。

列表需要 /L、/LI、/Lbl 和 /LBody。标签元素放项目符号或编号，正文元素放条目内容。项目符号如果被当成普通字符输入，或者画在列表结构之外，阅读器只会把它念成文字，丢失条目数量和嵌套关系。嵌套列表要嵌套 /L 元素，而不是用缩进模拟的一串段落。

表格的结构要求最高。/Table 包含 /TR 行，每行包含 /TH 表头单元格和 /TD 数据单元格，表头单元格应声明 /Scope 为 /Column、/Row 或 /Both。有合并单元格的复杂表格需要 /RowSpan 和 /ColSpan；不规则表头可能还要给表头设置 ID，并用 /Headers 让每个数据单元格指向正确的表头。表格题注应放在与表格关联的 /Caption 元素里。仅用于排版的布局表格不应标成数据表，而应作为伪影或简单的分组元素；否则阅读器会一本正经地宣布“表格，3 列，8 行”，只会让人困惑。

插图需要 /Figure，传达信息时还需要 /Alt。图注应标成靠近插图的 /Caption，不要把图注内容合并进替代文本，替代文本也不要简单重复图注。如果图片里有不可缺少的文字，要么把这段文字还原成真实文本，要么把原文准确写进替代文本。一段文字的截图不是可访问文本，哪怕它在屏幕上很清晰。

结构还必须完整。空元素、孤立内容和不属于任何元素的标记内容都会造成缺口。检查器可能报告“存在标签内容”，而页面中间仍有一段没打标签，只能按绘制顺序读出。逐元素检查标签面板，仍然是发现这类缺口最可靠的方法。

替代文本与装饰性图片

替代文本不是图片说明，而是这张图片对文档贡献的信息。“笔记本电脑的照片”通常没有用；“笔记本屏幕显示导出对话框，已选中 PDF/UA 选项”才告诉读者图中真正重要的内容。写“图表”比不写更糟，因为它隐瞒了图表存在的目的。

好的替代文本对简单图片要具体而简短，避免“图片展示”“照片中”这类不增加信息的开头。它不应重复已经会被读出的图注，也不应包含文件名。Logo 如果承担品牌识别，写品牌名就够了；每页页眉里重复出现的 Logo 属于装饰，应标为伪影。作为按钮的图标，替代文本要说明动作，而不是描述图形。

复杂插图无法压缩成一句话。多系列图表要么在文档其他位置提供详细文字说明，要么更好——提供包含数据的无障碍表格。替代文本可以总结结论，但装不下完整数据集。流程图可能需要逐步的文字等价说明。判断标准是：看不到图的读者，是否仍能完成这张图支持的任务。

装饰性图片应标为伪影，而不是给 /Figure 一个空 /Alt。空替代文本的插图仍可能被某些阅读器念成“插图”，而 PDF/UA 期望有意义的插图提供替代内容、纯装饰内容退出结构。背景纹理、分隔线、装饰边框和占位图都属于伪影层。

链接和控件遵循同样的逻辑。链接注释需要 /Contents 条目，或者有描述目的地的可见链接文字；裸 URL 和“点击这里”脱离上下文就没有意义。用图标做的表单按钮需要名称。检查器能确认替代属性存在，却无法确认这些词有用；这个判断需要理解文档目的的人来做。

文档语言、标题与元数据

文档语言决定辅助技术怎样发音。它存放在文档目录的 /Lang 里，使用 BCP 47 标签，例如 en-US、zh-CN、fr-CA。没有它，屏幕阅读器可能用用户界面语言去读另一种语言的全文，每个词都念错。设置之后，阅读器才能选择正确语音、应用正确的断词和拼写规则，并在语言切换时改变发音。

文档内部的语言变化需要在对应的结构元素或文本片段上单独设置 /Lang。英文报告里的法语引文、中文手册里的英文产品名、双语术语表，都需要这种标记。只设置文档级语言，处理不了混排内容；反过来，给每个段落都重复同一个语言，只会增加噪声。

文档标题是很多用户接触文件时听到的第一条信息。它存放在两个地方：信息字典的 /Title 和 XMP 元数据的 dc:title。设置 /ViewerPreferences << /DisplayDocTitle true >> 后，阅读器会在窗口标题栏显示这个标题，而不是文件名。final-report-v7.docx 不是标题，只是泄漏进元数据的文件名。PDF/UA 要求文档有标题，而且有意义的标题对每个按窗口或标签页导航的人都更有帮助。

与标签相关的元数据还包括 /MarkInfo << /Marked true >>、验证文件中应为 false 的 /Suspects 标志，以及 PDF/UA 符合性所需的 XMP 标识——pdfuaid:part 设为 1。作者、主题和关键词有助于检索，但不能代替标题和语言。从 Word、InDesign 或浏览器导出时，这些字段往往继承自源文件，导出后需要核对和修正。

顺序很重要，因为元数据修起来便宜，却最容易被忘记。标签完美、没有 /Lang、标题是文件名的文档，仍然会在用户接触它的第一秒就失败。

扫描版 PDF 与 OCR 文字层

扫描版 PDF 是纸张的照片。页面里是一张图片，不是字符，所以没有东西可打标签，也没有东西可读。扫描仪可以通过 OCR 生成“可搜索 PDF”，在图片下面加一层不可见文字。这层文字让文件可以搜索和选中，却经常被误当成无障碍。

OCR 不会创建结构。识别出的词按坐标摆放，不会自动变成标题、列表、表格单元格或插图。一份有清晰标题和数据表的扫描报告，可能变成可搜索页面：标题只是页面顶部的一段文字，每个表格单元格只是一个孤立的词。要让它无障碍，需要 OCR 之后再识别结构并人工修正：给标题打标签、重建列表、用表头单元格重建表格、为插图补替代文本、标记伪影，并检查阅读顺序。

OCR 还会引入错误，而屏幕阅读器会把这些错误原样念出来。常见替换包括 rn 识别成 m、0 识别成 O、1 识别成 l 或 I、5 识别成 S、8 识别成 B。中文 OCR 会混淆未和末、己和已和巳这类形近字。分栏可能被合并，表格单元格可能跨行串读，脚注可能被并进正文。不可见文字层还可能与可见页面不一致；这比没有文字层更糟，因为文件能通过天真的“可搜索”检查，却给出错误答案。

OCR 的语言设置有两重作用：它影响识别准确率，也应该影响文档的 /Lang。用英文 OCR 引擎处理中文扫描件，文字质量会很差；如果语言元数据一直不修正，屏幕阅读器还会用英文语音去读中文结果。手写、印章和复杂表单往往无法可靠识别到可以作为唯一无障碍版本的程度；这种情况下诚实的做法是同时提供无障碍 HTML 或标签化文本版本，而不是虚假声明符合标准。

发现问题只需要几秒。pdffonts 列出嵌入字体，扫描件通常一个都没有；pdfimages -list 显示每页是不是整页图片；在阅读器里选中文字能看出有没有文字层，但看不出文字是否准确。搜索一个已知的人名或数字，把高亮出来的文字和图片对照。

文本提取和 PDF 转 Word 会破坏什么

文本提取和 PDF 转 Word 是内容恢复工具，不是无障碍工具。它们有用，但会破坏辅助技术所依赖的那层结构。

PDF 转文本工具恢复的是字符。它不恢复标题、列表归属、表格单元格关联、替代文本、语言片段，也不区分正文和伪影。页眉、页码和脚注可能混进正文，多栏页面可能被一条完全不懂标签树的启发式规则拉平。输出适合搜索、翻译、摘要和喂给语言模型；它不是修复格式，从不无障碍的 PDF 里提取文字，也不会让这份 PDF 变得无障碍。

PDF 转 Word 工具更进一步，从页面几何位置猜段落、样式和表格。它能生成可用的草稿，但这种重建只是近似。视觉标题可能变成加粗段落，项目符号可能变成普通字符，合并单元格可能失去关系，文本框可能变成独立框架，替代文本通常会被丢掉，因为页面上没有可供反推的视觉对应物。生成的 DOCX 也许文字齐全，却仍然不可访问；再转回 PDF 只会生成一套继承近似结果的新标签，而不是原来的语义。

所以“把无障碍 PDF 转成 Word 再转回来”不是修复路径。正确方向恰好相反：先做一份无障碍源文档，使用真正的标题样式、真正的列表、表格表头行、替代文本和文档语言，再导出带标签的 PDF。在 Word 里，这意味着使用内置标题样式、把装饰图片标为装饰、在替代文本面板里补说明、让表格重复标题行，并在 PDF 导出选项里勾选“文档结构标签”。InDesign 有对应的标签 PDF 和文章顺序导出设置。

只有 PDF 时，修复应该发生在 PDF 结构里，而不是做格式往返。Acrobat Pro、PAC、axesPDF、CommonLook 之类的工具可以添加标签、修复阅读顺序、编辑替代文本。篇幅长、结构复杂又没有源文件时，从原始内容重建往往比逐个元素修复几千处更便宜，也更可靠。

页面级编辑同样要谨慎。PDF 页面编辑器适合删除空白页、旋转页面、裁剪或重排页面，但页面操作不会重建结构树。打完标签后再重排或删除页面，可能让 /StructParents 和父级树引用指向错误的页，或者留下 MCID 已经不存在的结构元素。尽量在打标签之前完成页面编辑；如果之后才改，要重新跑无障碍检查。页面编辑器保留的是外观，默认不保留语义。

表单字段、焦点顺序与交互内容

可填写 PDF 还有一层：AcroForm 字段和控件注释。每个字段在 /T 里存名称，在 /V 里存值，在 /Ff 里存必填、只读、多行等标志。屏幕阅读器宣布的可访问名称通常来自 /TU，也就是替代名称或工具提示。一个字段只有 cust_ref_2 这样的技术名称而没有 /TU，用户听到的就是 cust_ref_2，什么信息也没有。

字段还必须进入结构树。控件注释是页面对象，要通过结构中的对象引用被引用，并用 /StructParent 指回父级树。如果控件不在树里，阅读模式可能直接跳过它，或者把它按注释数组顺序放到页面末尾。看起来整齐的表单，离开鼠标可能完全没法用。

焦点顺序由页面的 /Tabs 条目控制。/Tabs /S 按结构树，/Tabs /R 按行，/Tabs /C 按列，/Tabs /A 按注释数组顺序。PDF/UA 期望结构顺序。没有显式设置时，Tab 顺序常常等于字段创建顺序，可能从表单底部跳到顶部再跳回来。阅读顺序和焦点顺序应当一致：键盘用户和屏幕阅读器用户应该走同一条逻辑路径。

标签、说明和错误提示是内容，不是装饰。字段标签必须是真实文字并和字段关联，不能是输入后消失的占位符。必填字段要在标签里说明，不能只靠红色星号或颜色变化。错误信息要能被宣布并关联到对应字段，不能只是一圈红框。签名字段需要名称和操作说明，用图标做的按钮需要可访问名称和可见的焦点状态。

XFA 表单是另一类问题。XFA 是旧版 XML 表单架构，很多辅助技术和非 Adobe 阅读器都不支持。要无障碍，通常需要把 XFA 转成 AcroForm，或者改用 HTML 表单。把表单压平成图片是最差的选择，因为它彻底移除了键盘操作。

测试表单要按真实使用方式：先只用键盘，再用屏幕阅读器的表单模式，逐个 Tab 经过所有字段，输入非法数据，确认标签、说明、必填状态和错误信息都按合理顺序被读出来。

对比度、测试、修复顺序与常见错误

颜色对比度是标签无法满足的无障碍要求。WCAG 要求普通文字至少 4.5:1，大号文字（约 18 点，或 14 点加粗）至少 3:1，界面组件和有意义的图形至少 3:1。这些比例针对渲染后的 PDF，包括图片里的文字。一份标签完美、却用浅灰字配白底的文件仍然不合格，再多的结构修复也改变不了眼睛分辨不出的内容。

对比度是内容设计问题，因为它在设计阶段就决定了，不在打标签时决定。只靠颜色传达含义也是同样的问题：链接只靠颜色区分、必填项只标红色、图表系列只靠色相区分。要改调色板，加下划线或纹理，并提供文字标签。验证时要采样实际渲染出来的颜色，不要相信样式指南里的品牌色；透明度、叠印和图片压缩都可能改变最终结果。

自动检查器是第一遍。Acrobat 的完整检查、PAC、带 PDF/UA 规则的 veraPDF 以及类似工具，能发现未标记内容、缺少替代属性、缺少文档语言和标题、部分表头问题以及表单字段问题。它们判断不了替代文本是否有意义、阅读顺序是否符合视觉逻辑、表头是否关联到正确单元格，也判断不了具体语境下的对比度是否足够。报告全绿只说明机械规则通过了，不说明文档可用。

屏幕阅读器是第二遍，也是决定性的一遍。从头读文档，按标题导航，跳到表格听表头如何宣布，Tab 经过表单，确认语言切换发音正确。至少用 NVDA、JAWS、VoiceOver 或 Orca 中的一个测试，交互内容还要做纯键盘测试。再把页面放大到 200%、覆盖文字间距测试，因为无障碍不只关乎辅助技术。

# 文件基本情况：是否带标签、页数、页面尺寸、PDF 版本。
pdfinfo contract.pdf | grep -E 'Title|Subject|Tagged|Pages|Page size|PDF version'

# 打印逻辑结构树，再按结构元素分组输出文本。
pdfinfo -struct contract.pdf
pdfinfo -struct-text contract.pdf | head -60

# 对比视觉布局和重建出来的阅读顺序。
pdftotext -f 1 -l 1 -layout contract.pdf - | head -40
pdftotext -f 1 -l 1 contract.pdf - | head -40

# 按 PDF/UA-1 验证，并列出未通过的检查项。
verapdf --flavour ua1 --format text contract.pdf | head -80

这些命令暴露的是不同层面的问题。pdfinfo 报告文件是否声称带标签、标题和语言元数据是什么。-struct 显示结构树，包括空元素和异常嵌套。-struct-text 显示理解结构的阅读器会提取出什么。两次 pdftotext 展示布局模式和默认启发式规则差多少，这本身就是一个提醒：两者都不是无障碍阅读顺序。verapdf 应用 PDF/UA 规则并报告机器可查的失败项，但它不能代替亲耳听一遍文档。

修复顺序和工具同样重要。先修源文档：使用真正的标题样式、真正的列表、表格表头行、替代文本、文档语言、有意义的元数据，以及能生成标签 PDF 的导出配置。再修 PDF：核对结构树，修复阅读顺序，标记伪影，修正标题和表格，补充或改进替代文本，设置语言和标题，检查表单。重新打标签是维修，修源文档才是预防。只在 PDF 上修过的文件，下次有人从源文件重新导出时还会退化。

扫描件的顺序是 OCR、结构识别、人工验证。没有源文件且篇幅短时，直接在 PDF 上修复是合理的；篇幅长、结构复杂时，用无障碍创作工具从内容重建通常更快，结果也更好。如果内容本身高度视觉化、无法用文字忠实表达，应发布无障碍替代版本，而不是声称符合标准。

常见错误，大致按出现频率排列：

• 把标签化 PDF 当成无障碍 PDF，不检查结构树。
• 发布时没有 /Lang，或者标题就是文件名。
• 用加粗和大字号代替真正的标题标签。
• 替代文本只描述图片是什么，不说明它传达的信息。
• 装饰性图片留成带空替代文本的插图，而不是伪影。
• 把布局表格标成数据表，或者数据表没有表头单元格。
• 以为做了 OCR 扫描件就无障碍了。
• 把绘制顺序当成阅读顺序，尤其在分栏和侧栏场景。
• 表单没有 /TU 名称、没有标签、没有基于结构的焦点顺序。
• 检查器通过就忽略对比度。
• 把转成 Word 再转回来当作修复手段。
• 打完标签后重排页面，却不重新验证结构。

发布前做一遍简短终检：确认标题和语言，走一遍标题层级，用屏幕阅读器读第一页，检查一个表格和一张插图，Tab 走一遍表单，再确认最小字号的对比度。目标不是拿到一个绿色对勾，而是让使用辅助技术的人能以和所有人相同的成本找到、理解并操作这份文档。