数学无障碍
MathML、MathJax与漫漫长路
二十年来，网页对散文的渲染游刃有余，对数学的渲染却一塌糊涂。Chromium 109中原生MathML的落地，以及悄然成熟的Speech Rule Engine，终于扭转了这一局面。本文梳理各组件之间的关联，并指明2026年应选择哪一个。
1. 2026年的原生MathML
首先直接说明：关于浏览器是否应该原生渲染数学的漫长而缓慢的争论已经有了定论。Firefox自2000年代初便能渲染MathML；WebKit于2013年在Safari中提供了可用的实现；最后的缺席者Chromium，终于在2023年1月的第109版本中落地了MathML Core。这一单一版本解锁了整个平台：截至2026年中期，所有主流桌面及几乎所有手机上的主要浏览器引擎都将MathML作为一等语言支持。网页近二十年来标准化的应急方案——将数学渲染为图像，附上屏幕阅读器用户不得不信任的alt属性——不再是负责任的默认选择。
2023年发生的变化比标题所暗示的要窄。Chromium并未实现完整的MathML 3；它实现了MathML Core，这是一个经过刻意限定的子集，覆盖浏览器能够可靠渲染且辅助技术能够导航的元素。初等数学排版（长除法、进位、竖式加法）不在Core范围内。长方程内的换行属于Core，但启发式方法较为保守。部分高级可伸缩运算符在不同引擎间渲染仍不一致。但骨架部分——分数、根号、下标和上标、矩阵、积分、求和以及运算符字典——现在已在每个重要引擎中得到支持。
无障碍影响是直接的。直接向DOM输出MathML的页面，提供了一个屏幕阅读器可以朗读、导航并以不同详细程度重新朗读的语义表达式。输出带有alt属性图像的页面，提供的是屏幕阅读器用户无法深入、无法重新朗读、无法复制到计算器的单一句子。十年来这是真实的权衡，因为Chromium无法渲染MathML，退而使用图像意味着页面损坏更少。这一权衡不再成立。
MathML Core是浏览器引擎商定可互操作发布的MathML 3子集。如果当前在构建流水线中输出MathML，目标应为Core。初等数学符号和高级排版扩展存在于更广泛的MathML 3规范中；将其视为渐进增强，仍可从MathJax兼容层中受益。
“输出带有alt属性图像的页面，提供的是屏幕阅读器用户无法深入、无法重新朗读、无法复制到计算器的单一句子。“
2. MathJax：从渲染器到兼容层
MathJax是在Chromium长期缺席期间维持网页数学可读性的桥梁。自2010年首次发布以来，MathJax接收源代码中的LaTeX或MathML，并输出任何浏览器均可渲染的样式化HTML或SVG。在其历史的大部分时间里，它是网页数学内容的主要渲染层——Wikipedia、arXiv、MathOverflow、Stack Exchange以及绝大多数学术出版平台都在每个页面上使用MathJax。
MathJax在2026年扮演的角色有所不同。随着Chromium原生渲染MathML，最后渲染器的工作已经完成。MathJax现在做的，也是其他任何工具无法企及的，是站在遗留LaTeX源代码前，将其转化为浏览器可以直接渲染的干净MathML。其v3和v4版本正是以此为目标进行了重写：LaTeX输入解析器已经成熟，MathML输出符合标准，运行时可以配置为输出MathML后退出，让浏览器接管排版工作。该库比关键路径页面所期望的更重，但它是网页上最可靠的LaTeX到MathML转换器。
3. LaTeX到MathML的实践：好标记与坏标记
网页上的大多数数学内容在上游某处有一个LaTeX源文件。问题在于LaTeX到MathML的转换在哪里发生——构建时、运行时，还是永不发生。在所有无障碍维度上胜出的模式是：构建时转换为MathML，并将渲染后的MathML直接输出到页面HTML中。在所有维度上失败的模式是：发布LaTeX渲染的图像，配上意译方程式的alt属性。
- 方程式以语义标记的形式存在于DOM中。
- 屏幕阅读器能朗读运算符、操作数、结构——并允许用户在子表达式中导航。
- 浏览器原生渲染；关键路径上无需运行时JavaScript。
- 搜索引擎和AI摘要工具可以将表达式作为文本读取。
- 复制粘贴产生可用的表示形式，通常可以往返转换为LaTeX。
- 方程式是平面图像；结构对辅助技术不可见。
- 屏幕阅读器朗读单一的alt句子；无法导航、无法重新朗读、无法控制详细程度。
- 图像在阅读器缩放和操作系统文字大小变化时缩放效果差。
- 搜索引擎和AI工具看到的是”方程式图像”，仅此而已。
- 复制粘贴产生PNG；读者无法将数学移入计算器。
许多CMS平台仍然在页面中直接输出原始LaTeX，让运行时库（通常是MathJax）在加载时发现并转换它。结果是能够渲染的，但只有在脚本运行之后——在慢速网络上这是不可忽视的无障碍代价，也是可测量的布局偏移成本。在能够时选择构建时转换；将运行时转换保留给无法重建的遗留源文件。
4. 屏幕阅读器数学导航
渲染数学只是工作的一半。另一半是导航：一个长方程式无法在不让读者迷失的情况下被线性化为单一朗读句子。每个主要屏幕阅读器现在都提供”数学模式”，允许用户进入分数内部、沿分子行走、深入下标、跳出到父表达式，并以不同详细程度重新朗读当前子表达式。各实现在成熟度、快捷键，以及最关键的——它们共享的语音规则库方面存在差异。
| 屏幕阅读器 | 原生MathML | 语音引擎 | 导航 | 成熟度 |
|---|---|---|---|---|
| NVDA（Windows） | 是 | MathCAT（现代），历史上使用MathPlayer插件 | 子表达式遍历、详细级别、盲文输出 | 生产就绪 |
| JAWS（Windows） | 是 | MathCAT | 子表达式遍历、仅数学审阅光标 | 生产就绪 |
| VoiceOver（macOS、iOS） | 是 | Apple内部，部分来源于MathML语义 | 项目选择器导航；精细度低于NVDA/JAWS | 可用，功能较少 |
| ChromeVox（ChromeOS、Chrome） | 是 | 直接使用Speech Rule Engine（SRE） | 通过SRE规则进行子表达式遍历 | 课堂环境中表现强劲 |
| Orca（Linux） | 部分 | 通过浏览器使用SRE；Orca本身依赖无障碍树文本 | 有限；取决于浏览器 | 不一致 |
MathPlayer是最初教NVDA朗读MathML的Design Science插件；它已经退役。MathCAT是其现代继承者——基于Rust积极维护，是目前NVDA和JAWS推荐的后端。MathML是标记语言本身：两个库都消耗这种输入。2026年规范或供应商文档中对MathPlayer的引用通常是历史性的，应在精神上理解为”数学语音插件”。
5. 默默运行于幕后的Speech Rule Engine
几乎所有现代网页数学语音体验背后，都有一个大多数工程师从未听说过的项目：Speech Rule Engine，简称SRE。SRE于2010年代中期在Google的ChromeVox团队内部启动，现在是一个主要由Volker Sorge维护的开源库。它接收MathML输入，输出结构化的语音形式——跨越多种语言、多个详细级别以及多个规则集（MathSpeak、ClearSpeak、ChromeVox-classic）。它也是MathJax在其自身渲染输出上暴露数学导航行为的引擎，并被MathCAT以及多个浏览器侧无障碍实验所引用。
SRE作为基础设施之所以重要，是因为如果没有规范的发音库，每个屏幕阅读器都会以自己的方式朗读x squared plus y squared equals r squared。有了SRE，主要实现正在向一小组经过认可的规则集收敛，这意味着在教材创作工具中编写方程式的教师，可以大致预测使用NVDA、JAWS或ChromeVox的学生会如何听到它。这种收敛并不完整——VoiceOver是例外——但它是真实的，并且在增长。
MathSpeak与ClearSpeak
SRE内置两个最知名的规则集。MathSpeak是较旧的、更字面的风格——“fraction one over two end-fraction”——专为盲文式精确性而设计。ClearSpeak是较新的、听起来更自然的风格——“one-half”——是当今大多数课堂部署中的默认选项。在两者之间切换是一种详细程度风格偏好，而非不同的引擎。
多语言支持
SRE提供英语、法语、德语、意大利语、西班牙语以及越来越多其他语言的翻译规则集。这些翻译不是机器生成的——它们由SRE维护者和贡献者，在用这些语言教授数学的教育者的帮助下编写。这是网页无障碍领域少数几个本地化真正完整到可以依赖的地方之一。
盲文输出，不只是语音
SRE也能从MathML输出Nemeth和UEB-math盲文，这是大多数现代盲文显示器用于渲染数学的路径。驱动语音输出的MathML源文件同样驱动盲文输出，这正是无障碍基础设施层应当具备的架构特性。
6. 按文档类型提供的建议
通用原则——输出MathML，在可能时从LaTeX构建时转换，依靠SRE处理语音——适用于每种文档类型。具体细节随载体而变化。以下是无障碍团队交付的四类最常见文档的具体建议。
网页文章和博客
如果平台支持，直接将MathML渲染到文章正文中——大多数静态站点生成器可以在构建时调用Temml或Pandoc并将MathML输出到HTML中。如果平台是只接受LaTeX的遗留CMS，以MathML输出模式加载MathJax v4并让其在运行时转换，但要积极使用缓存。不要发布方程式的PNG图像。
学术期刊论文
语料库绝大多数是LaTeX格式，出版流水线是正确的转换位置。Pandoc、批处理模式下的MathJax或出版商自己的LaTeXML流水线可以在同一次运行中同时输出带MathML的HTML和PDF。无障碍收益巨大：在线阅读论文的屏幕阅读器用户获得的是可导航的方程式，而非数学被栅格化的PDF。将HTML/MathML输出与标记PDF版本配对，供离线阅读使用。
教材和长篇课件
嵌入MathML的EPUB 3是标准格式，现代阅读系统（Apple Books、Thorium、经ACE测试的生产阅读器）能够正确处理。在MathML中一次创作，向视力正常用户和屏幕阅读器用户发布相同的EPUB，并依靠辅助技术层中SRE驱动的语音。避免将方程式烘焙为栅格图像，即便排版看起来更漂亮——无障碍代价不值得换取这一美化。
课堂幻灯片和实时教学
幻灯片是最混乱的载体——PowerPoint和Google Slides各自以不同方式处理数学，演示者模式通常退回为图像。2026年可辩护的默认做法是：在能够导出MathML的幻灯片工具中创作数学（或将幻灯片以HTML形式撰写），并在讲座前向学生分发包含相同方程式（以MathML形式）的配套HTML或EPUB讲义。讲义——而非幻灯片组——才是屏幕阅读器学生在课堂内外都能导航的文档。
对于全部四种文档类型，同一个单一原则适用：输出MathML，让浏览器渲染它，让SRE驱动的语音和盲文处理辅助技术层，并将产生方程式图像的任何流水线视为需要修复的失败。2023年浏览器引擎的收敛使这一原则终于负担得起。屏幕阅读器在SRE上的收敛使其终于保持一致。
结论：漫漫长路，终有所向
网页数学无障碍是主要无障碍前沿中成熟最慢的。标准在1998年便已就绪。屏幕阅读器在2000年代中期就已基本准备好。浏览器引擎等到了2023年。这三层之间的整合——标记、渲染、语音——只是在那年下半年才真正衔接到位：随着MathCAT取代NVDA内部的MathPlayer，随着JAWS采用相同后端，随着ChromeVox和MathJax在同一底层Speech Rule Engine上收敛。
剩余的工作在边缘地带。初等数学符号不在MathML Core中，教授低年级算术的平台仍须退回MathML 3扩展或图像。VoiceOver的数学导航可用，但精细度低于Windows用户所获得的体验。浏览器在很长方程式内的换行处理保守，部分可伸缩运算符在各引擎间渲染仍不均匀。这些是真实问题，值得修复。但它们与2023年之前十年”Chromium根本无法渲染数学”是不同性质的问题。
对于2026年正在发布包含数学内容的新产品界面的工程团队，可辩护的默认做法是：输出MathML，在源文件允许时从LaTeX构建时生成，对无法预处理的遗留LaTeX退回MathJax v4，并信任屏幕阅读器技术栈——NVDA加MathCAT、JAWS加MathCAT、ChromeVox加SRE、VoiceOver原生——来处理语音层。漫漫长路尚未结束。但有史以来第一次，它通向了可以阅读的地方。
“标准在1998年便已就绪。浏览器引擎等到了2023年。整合在那年下半年才真正衔接到位。“