Pdf.js: 包括对标记 PDF 的支持

添加了 [triage-needed] 标签。 我们是否需要一个新标签（4-tagged-pdf）来进行与标记 PDF 相关的开发？

我们有示例 PDF 吗？ 我个人从未见过这样的 PDF。 它们在实践中的使用频率如何？

是的，我们有几个：

$ cd test/pdfs/
$ grep -rla '/Marked true'
i9.pdf
fips197.pdf
issue1169.pdf
smaskdim.pdf
issue3879.pdf
bug816075.pdf
pdf.pdf
issue1709.pdf
f1040.pdf
wdsg_fitc.pdf
annotation-border-styles.pdf
ecma262.pdf
bug887152.pdf
issue1133.pdf
issue2442.pdf
issue1796.pdf
type4psfunc.pdf

如果需要更多， https ://encrypted.google.com/search?q

谢谢！ 在这种情况下，研究这个肯定很有趣。

我认为使用 HTML 和 ARIA 属性的混合来实现这一点可能相对容易 - 不需要更改渲染 - 只需添加一些新属性。

PDF 标记信息存储在 StructTreeRoot 树中，其中包含具有可访问性信息的结构元素，例如替代文本、语言和语义类型（H1、TH、LI 等）。 结构元素包含对页面内容流中对象的引用。 有一个图形显示这里：
https://stackoverflow.com/a/34047585

我认为您可以使用以下内容在_layoutText(textDiv)注入 PDF 标记信息：

1）在StructTreeRoot树中查找被渲染的PDF对象对应的结构元素
2) 如果结构元素具有 H1、H2、LI 等结构类型，则向 div 添加role属性。
3) 如果结构元素有 /Alt 条目，则向 div 添加aria-label属性
4) 为结构类型H1-H6的标题级别对应的div添加aria-level属性

这应该使屏幕阅读器可以访问标题、列表和图像。 表格的实现可能更复杂。

PDF 结构类型在第 14.8.4.3 节中列出。 的
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

对于标题，渲染将从此改变：

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);">
7.  Evaluation
</span>

对此：

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);" 
role="heading" aria-level="1">
7.  Evaluation
</span>

然后屏幕阅读器将其读作“7. 评估，标题级别 1”，更重要的是让用户可以使用“下一个标题”键在标题之间跳过（这使得大型文档更容易导航）

我注意到 4-tagged-pdf 标签已被删除。 这仍然是正在追求的东西吗？

开放的问题表明我们正在考虑它。 这是一项功能，标签已重新排序。

哇，太棒了！ 正在考虑的此功能是否包括对生成标记 PDF 的支持？ 它可以促进为现有 PDF 实现诸如解析器/分析器之类的东西，但它也将为生成 508c PDF 提供支持。

生成 508c PDF 所需的核心功能：

• 标记文档（使用语言和标题，可能还有其他标签）
• 标记 PDF 中的结构对象（标题、表格、th、td、列表等）
• 向视觉媒体（图像、视频、数字等）添加替代文本
• 创建/维护元素的 Tab 键顺序

如果这 4 件事存在核心功能，那么就有可能在生成 508c PDF 的 PDF 生成过程中实现逻辑。 老实说，这将是巨大的，因为我还没有找到任何支持此功能的开源 javascript 工具。

写完这篇之后，我不确定这是否符合单独的功能请求……如果是这样的话，我很乐意创建一个新问题。

我一直在与@cuhaller合作，以更好地遵守 WCAG 2.0 的 SC 2.4.10 和 1.1.1，以针对其团队正在开发的应用程序的特定用例。

我相信这些变化应该足以满足这个问题需要完成的一部分。 我将在下周左右按照贡献指南提交 PR。 当我提交时，我会更新这个线程。

我在 PDF.js 2.3.200 的 fork 中进行了更改，以提供位于此 repo 的Headings

我对打开 PR 犹豫不决，因为存在与 master 的合并冲突，我目前没有时间解决它们。

如果有人有空让这个分支与 master 保持同步，让我们联系！

Edge 吹捧了对标记 PDF 的原生支持。 Chrome 现在也支持它，并且还吹捧了它即将推出的从网页导出带标签的 PDF 的能力。

今天，Firefox 不会将 PDF 中的标记暴露给可访问性树/可访问性 API。 但是，此文本位于Firefox 80的

现在可以将 Firefox 设置为默认的系统 PDF 查看器。

如果依赖 AT 的用户这样做，或者不知道用户组成的系统管理员这样做，对于那些依赖 Edge、Chrome 或 Adob​​e Reader 为他们解析标记的 PDF 的用户来说可能会出现问题.

我强烈建议从 80 的发行说明中删除建议，并提高此错误优先级。 我知道 Mozilla 现在资源受限，但是宣传在竞争浏览器中更好地服务的无法访问的功能的光学效果并不好看。

我们的组织正在寻求为辅助技术用户实施可访问的 PDF 解决方案。 我们得出的结论是，由于缺少语义标记，因此无法使用 PDF JS 预览 PDF。 语义信息的缺乏给与屏幕阅读器软件交互的用户造成了障碍。 虽然 PDF 确实以纯文本显示并宣布注释，但不提供标题、表格、图像或链接的标记。

对于屏幕阅读器用户来说，围绕表格的用例尤其困难。 缺乏语义标记的表格无法为用户提供上下文，屏幕阅读器用户也无法完全理解 PDF 中显示的信息。

链接被公布为 URL 而不是特定的链接文本，这使得理解链接的目的变得困难。 我们建议链接使用可见的链接文本而不是链接 URL，以便用户在上下文中理解链接。

如果没有这种支持，我们对广泛实施 PDF JS 感到担忧。 是否有任何更新或时间表支持提供语义标记的功能？ 我们要求将此问题视为更高优先级，因为它会影响用户感知内容并与之交互的能力。

据我所知，非常欢迎贡献

感谢@trjohnst在这方面所做的工作。

我开始在 pdf.js master 上手动重新设置@trjohnst的分支。 这种方法适用于只需要一个级别的标签； 例如带有替代文本的标题或图像。 在遍历内容流时，如果遇到标记内容序列，它会查找关联的结构元素并将适当的 ARIA 角色放置在 pdf.js 文本层输出的 HTML 中的文本跨度上。

不幸的是，这对于需要嵌套标签的任何东西来说还不够； 例如列表或表格。 我不认为该方法可以扩展到涵盖这些，至少不是没有很多棘手的边缘情况。 此外，为了正确支持链接和表单字段（并注意在@trjohnst的贡献时

与其尝试在文本层中执行此操作，我认为我们将需要遍历结构树并基于此渲染节点，在我们输出的元素上设置 ARIA 属性。 结构树可以引用文本层和注释层中的数据。 我们可以根据结构树对文本和注释层 DOM 节点重新排序（在不破坏视觉渲染的情况下可能会很棘手？），或者使用 aria-owns 重新排序 a11y 树而不重新排序 DOM。

在架构上，这很棘手，因为文本和注释层已经分别呈现，现在我们需要查看第三层（或至少是事实来源），结构树，它可以移动（或引用）两个层中的节点其他层。 最简单的方法可能是将 id 附加到每个标记内容序列（在文本层中）和链接/表单字段（在注释层中）。 我看到表单字段已经有一个指定 id 的数据属性。 如果我们要使用 aria-owns，无论如何我们都需要设置 id 属性，这样可能会用一个烤饼喂两只鸟。 id 需要是我们可以从文本和注释层外部，从我们的新结构层内部计算出来的东西。 当我们处理结构树时，我们将输出结构元素的元素，根据它们的 id 从文本/注释层移动/拥有元素。

超越标记 PDF 到启发式，我们需要能够执行以下操作：给定链接或表单字段注释，其矩形是否包含文本层中的某些内容？ 如果是，则注释应与其文本相关联（aria-owns 或 DOM move）。 同样，这在架构上很棘手，因为文本和注释层（及其输入）是分开的，我认为我们可以使用的那些层没有任何缓存状态。 然而，我们可以潜在地查看由文本和注释层呈现的节点的边界，尽管这开始模糊内容和表示处理之间的架构边界。

虽然标记 PDF 的初始实现不一定需要支持启发式，但我强烈建议将其视为架构设计的一部分。 现实情况是，未标记的PDF文件是不幸非常普遍，它也很不愿意被锁定在一个架构，它不允许这些被更多的人使用。 （请注意，Acrobat Reader 以及较小程度的 Chromium 使用启发式方法来尝试使未标记的 PDF 更易于访问。）