无障碍PDF全流程：
从内容创作到无障碍修复
PDF无障碍并非在Acrobat中最后拨动一个开关就能完成的事情。它是一系列决策的链条：始于InDesign或Word，贯穿标签树，达到PDF/UA合规性，经PAC验证，最终面对四种屏幕阅读器——而每种阅读器处理同一文件的方式都略有不同。本指南按工程师的实际工作顺序逐一梳理这条链条。
1. 内容创作：选择一款切实可用的上游工具
决定后续所有步骤的关键抉择，是排版环境的选择。由一份结构严谨的InDesign文档生成、并应用了无障碍操作（Make Accessible action）的PDF，在任何人打开Acrobat之前就已携带了80%的无障碍元数据。而从一份用粗体和字号变化来”伪造”标题的Word文档导出的PDF，几乎不带任何结构信息，无论下游修复做多少工作都难以完全弥救。换言之，排版工具的选择并非关乎审美，而是关乎结构。
2026年，机构出版领域有三条主要生产路径。Adobe InDesign配合无障碍操作是排版文档的行业标准——年报、教科书、法规申报材料等布局固定、仅由设计团队发布一次的文件皆适用。Microsoft Word配合”另存为无障碍PDF”是办公文档的主力工具——政策文件、合同、信函等持续编辑、PDF作为渲染输出而非最终归档的场景适用。LibreOffice配合PDF无障碍检查器（PDF Accessibility Checker）交接流程，是出于政策原因回避Microsoft和Adobe技术栈的政府机构及高校所采用的开源路径。
由InDesign和Word生成的标签树，在结构上是从段落样式派生而来的；由修复工具生成的标签树，则是事后强加的。前者可与源文档对照审查，后者只能与自身对照。越来越多的审核方要求查看源文档，而不仅仅是PDF文件。
2. 标签树：每份无障碍PDF的实际组成内容
每份无障碍PDF的底层都有一个平行的逻辑结构——标签树——与视觉布局毫无关联。可见的PDF是以坐标寻址的绘图指令集。标签树则是一个独立的层级式文档对象模型，用于说明：这段绘图操作是第一级标题，那段是第二个列表的第三个项目符号项，这张图片是纯装饰性的，另一张图片的替代文本为”按季度分部门的FY24营收”。屏幕阅读器读取的是标签树，而非绘图内容。
在实际文档中，六类标签承载了绝大部分语义：标题（H1至H6）构成可导航的大纲；段落（P）是散文段落；列表（L、LI、Lbl、LBody）是有序或无序的枚举；表格（Table、TR、TH、TD）是通过Scope属性公开列标题和行标题的数据网格；图形（Figure）通过Alt或ActualText属性承载替代文本；阅读顺序由标签树本身的深度优先遍历决定，规定了屏幕阅读器朗读文档的顺序。一个视觉上看起来正确的双栏页面，如果标签树将右栏放在左栏之前，阅读顺序就会出错。
在规范生成的文件中，每个标签还有两个属性至关重要。语言属性（Lang）告知屏幕阅读器应使用哪本发音词典——英文段落中引用的法语内容，需要在Span标签上添加自身的Lang属性，否则将以英语音素朗读。工件标记（artifact marker）区分装饰性内容与结构性内容；页眉、页脚、页码和装饰性分隔线均应标记为工件，以便屏幕阅读器跳过。
Sect → H1（页面标题）→ P（引言）→ H2（左栏标题）→ P、P、L/LI × 3 → H2（右栏标题）→ P、P → 带Alt的Figure → 含TH(Scope=Col)和TH(Scope=Row)的Table。阅读顺序遵循树结构。页眉标记为Artifact。
单个扁平Sect，所有内容均为无类型P标签。标题是字号更大的P标签。列表是散文中带有项目符号字形的P标签。图形没有Alt。阅读顺序在各栏间逐行交替，因为标签树镜像了按列逐列排列的绘图顺序，而非逻辑顺序。
Acrobat的阅读顺序工具在视觉页面上显示与标签树遍历对应的编号覆盖层。仅根据视觉布局进行验证的工程师会遗漏阅读顺序错误，因为视觉布局可能是正确的，而标签树遍历顺序却是混乱的。务必同时打开标签面板并使用屏幕阅读器进行验证。
3. PDF/UA合规性：ISO 14289-1的实际要求
PDF/UA是无障碍PDF的国际标准，以ISO 14289-1发布于2014年，并于2024年更新。WCAG是技术中立、平台中立的；PDF/UA则专门针对PDF格式——它是文档生产软件、文档消费软件和辅助技术之间的契约，声明：该文件的标签树、元数据和结构符合一套可验证的条件，因此合规的阅读器可以依赖这些条件。
该标准通过Matterhorn协议落地实施，由PDF协会维护，将PDF/UA分解为31个编号的故障条件，每个条件均有机器可检查变体和人工可检查变体。机器可检查的故障包括：元数据中缺少文档标题、存在没有Alt或ActualText的图形、列表结构未在L/LI标签内、文档或语言切换段落缺少语言属性等。人工可检查的故障涵盖软件无法自行验证的内容——图形上的替代文本是否真实描述了图形内容、阅读顺序是否与逻辑顺序一致、标题是否有逻辑层级而非跳级等。
2024年更新将PDF/UA与WCAG 2.2成功标准对齐，并明确了数字签名和表单的处理方式——无障碍PDF表单必须公开字段标签、字段提示和Tab顺序；签名后的PDF不得阻止屏幕阅读器在签名后访问底层标签树。
”PDF/UA合规性是底线，而非上限。一个文件可以通过全部31项Matterhorn条件，但如果替代文本过于笼统或阅读顺序在技术上有效却语义错误，阅读体验依然糟糕。“
4. 修复工具：工程师实际会选择的四款产品
当一份PDF没有可用的标签树时——大多数遗留PDF都是如此——工程师的选择缩小到四种修复环境。每种工具在标签树编辑、扫描件OCR、批量处理和PDF/UA报告等方面各有优劣。下方矩阵表将能力与工具一一对应。
| PAC 2024 | Adobe Acrobat Pro | Foxit PDF Editor | ABBYY FineReader 16 | |
|---|---|---|---|---|
| PDF/UA完整报告 | 有（权威） | 部分（预检） | 部分（自有检查器） | 有限 |
| 应用内编辑标签树 | 不适用（只读） | 有 | 有 | 有 |
| 扫描PDF的OCR | 不适用 | 有 | 有 | 有（同类最优） |
| 阅读顺序覆盖层 | 只读 | 有（触摸式阅读顺序工具） | 有 | 有限 |
| 批量/脚本化修复 | 不适用 | 有（操作） | 有（操作） | 有（热文件夹） |
| 符合Matterhorn的输出 | 有 | 近似 | 近似 | 有限 |
| 费用区间 | 免费 | 订阅制 | 买断或订阅 | 买断 |
PAC是业内唯一被广泛信任的PDF/UA验证工具，但它不能编辑。大多数生产团队将PAC与Acrobat Pro（默认）或Foxit（许可规则要求替代方案时）搭配使用，仅在源文件是需要OCR才能构建标签树的仅含图像扫描PDF时，才会使用ABBYY。
5. 四款屏幕阅读器如何处理带标签的PDF
正确加标签的PDF只是链条中生产方的一半。另一半是屏幕阅读器。用户实际部署的四款阅读器在处理同一文件时存在细微差异。这些差异至关重要，因为在JAWS中阅读流畅的文档在NVDA中可能出现问题，而在macOS VoiceOver中正常显示的文件，在Chrome内置PDF查看器中被ChromeVox打开时，行为可能有所不同。
JAWS在所有商业屏幕阅读器中对PDF的支持最为深入且历史最长。其PDF模式通过Acrobat或Acrobat Reader渲染带标签的PDF，并直接公开标签树——标题列表（Insert+F6）、表单列表（Insert+F5）、使用标准JAWS表格键进行单元格导航。当PDF缺少标签时，JAWS会主动推断结构，但推断结果并不可靠；工程师不应依赖JAWS推断的内容进行验证。
NVDA同样通过Acrobat或Acrobat Reader读取带标签的PDF，其浏览模式导航与网页模式相似——按H跳转标题，按K跳转链接，按T跳转表格。NVDA的PDF支持自2022年以来有了显著改善，但在处理复杂表格和表单字段方面仍落后于JAWS。NVDA对标签格式错误的文档能给出更诚实的反馈：JAWS可能继续坚持阅读，NVDA则倾向于静默，这在诊断上颇为有用。
VoiceOver在macOS上通过Preview和Safari读取PDF，使用旋转器导航（VO + U）浏览标题、链接、表格和表单字段。VoiceOver是四款阅读器中最宽容的——即使对于标签不完善的文件，它也会重建阅读顺序——但这种宽容可能掩盖真实的问题。在VoiceOver中阅读尚可的文档，仍应针对JAWS或NVDA进行验证，而非反过来。
ChromeVox在ChromeOS上，以及所有屏幕阅读器与Chrome内置PDF查看器交互时，属于另一个类别。Chrome的PDF查看器会对页面进行栅格化并重新提取文本，而非渲染原始标签树，因此即使标签树干净的PDF在Chrome中直接打开时，也可能丢失大量结构。在对无障碍要求较高的场景中，解决方法是强制下载文件并在Acrobat Reader中打开，或提供HTML替代版本。
| JAWS · Acrobat | NVDA · Acrobat | VoiceOver · Preview | ChromeVox · Chrome查看器 | |
|---|---|---|---|---|
| 标签树保真度 | 高 | 中高 | 中 | 低（重新提取） |
| 标题导航 | 有（Insert+F6） | 有（H键） | 有（旋转器） | 有限 |
| 带TH范围的表格 | 有 | 有（2022年后改善） | 有（旋转器） | 常被展平 |
| 表单字段 | 有 | 有 | 有 | 有限 |
| 语言切换 | 有（Lang属性） | 有 | 有 | 不一致 |
| 标签格式错误时的行为 | 继续阅读 | 倾向于静默 | 重建结构 | 重新提取 |
如果只有时间测试两种组合，选择JAWS+Acrobat（受监管行业的机构默认选择）和NVDA+Acrobat（免费开源基准）。两者合力覆盖的范围，与四款阅读器全面测试的效果大致相当——除ChromeVox特定边缘案例外。
6. 端到端工作流程：按实际执行顺序排列
将整条链条串联起来：一份无障碍PDF需经历六个具体步骤。这些步骤是顺序执行的——跳过任何一步，都会导致文件在后续步骤或用户手中出现问题。
在标签感知工具中进行创作，并映射段落样式
选用InDesign（段落样式映射至导出标签）、Word（应用内置样式，不伪造标题）或LibreOffice（应用标题和列表样式）。标签树从这些样式映射中生成。
启用无障碍操作导出
InDesign：文件 → 导出 → PDF，选择带标签的PDF并运行无障碍操作。Word：文件 → 另存为Adobe PDF，或另存为PDF并勾选用于无障碍的文档结构标签选项。LibreOffice：文件 → 导出为PDF，勾选带标签的PDF和使用参考XObjects。
在Acrobat或Foxit中验证标签树
打开标签面板，逐级遍历树结构，确认标题嵌套逻辑正确、列表为L/LI/Lbl/LBody结构、表格TH带有Scope属性、图形有Alt或ActualText属性，装饰性元素标记为Artifact。运行工具 → 无障碍 → 阅读顺序，以数字方式验证阅读顺序。
运行PAC获取权威PDF/UA报告
PAC生成Matterhorn协议报告中机器可检查的部分。解决所有红色标记。请注意，PAC的绿色标记仅通过31项机器可检查条件；人工可检查条件（例如替代文本是否有意义）仍需人工核查。
至少用两款屏幕阅读器进行测试
最低限度为JAWS+Acrobat和NVDA+Acrobat，若目标受众包含macOS用户，还需加上VoiceOver。通过标题、表格、表单字段进行导航。确认语言切换时能以正确的语音朗读。确认阅读顺序与逻辑顺序一致。
发布并对源文件进行版本控制
可交付成果是PDF，但可维护的制品是带有段落样式映射的源文档。两者均需存档。文档需要更新时，从源文件重新导出并重新验证——除非源文件不可恢复，否则不要直接编辑已发布PDF的标签树。
结语：无障碍PDF生产是一条链条，而非一个复选框
将PDF无障碍视为最终修复问题的团队，最终会为此付出双倍代价——一次是修复一份在没有结构意图下生成的文件，另一次是每次更新该文件时重复这一过程。将其视为创作问题的团队，则在源头构建标签树，每次修订时干净地重新生成，将PAC和屏幕阅读器用于验证而非修复。两种方式之间的成本差异巨大；无障碍性上的差异则更大。
上述链条在每个环节都刻意保持工具无关性。无论上游是InDesign还是LibreOffice，编辑工具是Acrobat还是Foxit，验证工具是PAC，屏幕阅读器是JAWS还是NVDA，结构逻辑都是相同的：段落样式映射至标签，标签符合PDF/UA，PDF/UA经PAC验证，屏幕阅读器读取结果。工具会变，链条不变。
对于采购和合规团队而言，实际含义是：PDF无障碍声明应引用生产链——排版工具、导出操作、验证工具——而非仅仅引用Acrobat检查器结果。对于工程团队而言，含义是：标签树是事实来源，而标签树在用户看到任何PDF之前就已在上游构建完毕。关于与本指南互补的实操生产演练，请参阅PDF无障碍分步操作手册。
“无障碍的PDF，是那份标签树经过精心创作的PDF，而非那份标签树被临时修补的PDF。“