读屏软件把那段波兰语用英语的嘴念完，而页面上一个字符都没写错

摘要：页面上的字有两个出口，一个给眼睛，一个给耳朵，而耳朵那个出口的开关是lang属性。搜索引擎读到写错的语言标签会自己重新判一遍，屏幕阅读器不判，它照着那个值挑发音引擎，一个字母都不商量。于是同一个错误在检索侧只是概率变差，在朗读侧是百分之百念成另一门语言。

屏幕上没有一点问题的那一页，念出来为什么成了另一门语言？

一家二手书店的波兰站，客服收到的投诉里带着一个奇怪的词

有个客户做二手书跨境，波兰、捷克、希腊三个市场。

书这个品类的特点是标题极长，作者名、原名、译名、出版社、版次全挤在一行里。

那一季他们收到一封波兰用户的邮件，说你们网站听起来像一个说英语的人在念波兰语单词。

客服看不懂这句话，因为网站上的字明明是波兰语，一个英文都没有。

邮件里还提了一句，说他用的是免费的读屏软件，平时看别的波兰站都好好的。

团队第一反应是这是个孤例，一个视障用户的软件设置问题，跟网站没关系。这个判断在当时看起来完全合理，因为所有人都能打开这个网站，屏幕上什么毛病也没有，而对方描述的现象既没法复现，也不在任何一张检查表上。

三个人分别打开页面，三个人都说没问题

他们按流程走了一遍排查。

前端打开源码，标题、正文、按钮，全是波兰语字符串。

内容负责人对了一遍译稿，母语译者交付的版本和线上的一致。

技术负责人跑了一遍页面体检工具，没有任何警告。

三个人得出同一个结论：网站没问题，是用户那边的事。

这个结论在他们能用的所有工具下都成立，因为这三个人做的都是同一件事，用眼睛去看那份源码。而用户描述的是耳朵听到的东西，那条链路上还有一个环节，那个环节不在源码里，也不在任何一个人的检查动作里。

问题出在那一行谁都不会去改的模板代码上

他们的站是从一套英文模板改的。

翻译工作从页面正文开始，一直做到按钮和提示文案。

唯独文档最外面那一层的开头那行代码，没有人动过。

那行代码上写着这一页是英语，而页面上的每一个字都是波兰语。

这个矛盾在屏幕上完全没有表现，因为浏览器渲染字符时不问这一页是什么语言。

但是读屏软件问。它拿到这一页之后要做的第一件事，就是决定用哪一套发音规则把这些字符念出来，而它做这个决定的唯一依据，就是那行没人动过的代码。于是波兰语的字符串，被一台按英语规则工作的发音机器逐字念了出来。

把这件事翻译成一句能开会用的话

页面上的字有两个出口。

一个出口通向眼睛，走的是字体和排版这条链路。

另一个出口通向耳朵，走的是语言标签和发音引擎这条链路。

做多语言站的人在第一条链路上投入了全部精力，第二条链路的开关多数时候还停在模板的出厂值上。

这两条链路的检查方式完全不同，第一条用看的，第二条只能用听的。

而团队里没有人有听的习惯，验收清单上也没有这一项。所以这个开关可以在错误的位置上停很多年，期间网站改过版、换过模板、加过市场，谁都不会碰它，因为它从来没有让任何一个人看到过异常。

这件事只在多语言站上成立

英语站上这行代码写着英语，内容也是英语，两边天然对得上。

模板的出厂值就是英语，于是英语站永远不会踩这个坑。

这也是为什么整个前端行业对这件事的讨论度那么低。

它不是一个被忽视的问题，它是一个在英语世界里根本不存在的问题。

保哥这些年看下来，凡是英语站天然免疫的那一类坑，中文资料里基本查不到，因为最初的讨论就发生在英语社区。

这条判据在本站已经成立过很多次，比如小写折叠在土耳其语上会改坏词形，比如非字母字符默认就是词边界。它们的共同点是：错误的默认值在英语上恰好等于正确答案，于是没有人需要把它写成一条规则。语言标签是这一族里最贵的一条，因为它一错就是整页。

搜索引擎会自己重新判一遍语言，读屏软件为什么一次都不判？

先说清楚这两个消费方拿这个属性去干什么

同一个语言标签，页面上只写一次，读它的人不止一个。

搜索引擎读它，是为了给这一页归档到某个语言的索引里去。

浏览器读它，是为了决定断词规则、日期格式和默认字体。

读屏软件读它，是为了挑一套发音规则。

还有翻译提示、拼写检查、部分样式规则，也都在读它。

这些消费方拿到的是同一个字符串，但是它们对这个字符串错了之后的容忍度完全不一样，而这个差别才是整件事的关键。多数人默认所有消费方都一样宽容，因为在自己那一侧看不出区别。

引擎那一侧留了一道兜底

搜索引擎不会完全相信你写的语言标签。

它有自己的语言识别模型，会拿页面上的实际文本再判一次。

官方文档写得很直接，判定页面语言时用的是页面上可见的内容，而不是那些标记。

这意味着你把语言标签写错，引擎多半还是能把这一页归到正确的语言里去。

不是每次都能，短文本、混排页面、模板页上它会判错，页面被机器认成另一门语言这一层的账本站另有一篇专门算过。

但是至少它有兜底动作。它拿到一个可疑的输入，会去找第二个证据来源，这在工程上叫防御性设计。写错语言标签在检索侧的后果是概率变差，不是确定性失败。

读屏那一侧一道兜底都没有

屏幕阅读器不做语言识别。

它拿到那个标签，直接去发音引擎列表里找对应的那一个。

找到了就用，找不到就退回用户设置的默认语音。

整个过程里没有任何一步会去看看这段文本实际上是什么语言。

这不是产品做得不好，是这么设计才对。

辅助技术必须可预测，用户按下朗读键，得到的结果每次都要一样。一个会自己猜测、自己纠正的读屏软件，对依赖它工作的人来说是灾难。所以它把语言标签当成指令而不是建议，你写什么它执行什么。这句话反过来说就是：这个属性在朗读这一侧是硬约束。

同一个错误，两侧的结算方式差在哪

检索侧：写错了，引擎自己判，多数情况下没事，少数情况下这一页的语言归档变差。

朗读侧：写错了，百分之百用错的发音规则念，每一次都错，每一个用户都错。

检索侧的损失是统计意义上的，看报表能看出趋势。

朗读侧的损失是确定性的，但是它不进任何一张报表。

一个是概率变差但可观测，一个是必然发生但不可观测。

这一对反差解释了为什么这件事能长期没人管：在能看见的地方它不严重，在严重的地方看不见。做技术决策的人手上的所有信号都来自第一侧，于是这个属性的优先级永远排在后面。

这条原语在别的地方也成立

凡是一个字段被两个系统消费，而其中一个有兜底另一个没有，风险就全部压在没有兜底的那一侧。

结构化数据里的语言字段也是这个结构，填错了引擎会用正文纠偏，别的消费方不会。

商品数据源里的语言设置同样如此，页面侧有三处声明可以互相印证，数据源侧只有后台一个下拉。

判断一个字段值不值得单独立规矩，看的不是它出现在几个地方，是它的消费方里有没有一个是不做校验的。

只要有一个，这个字段的正确性就必须在写入的时候保证，不能指望下游修。

保哥把这条当成排查多语言站的第一把尺子。拿到一个站，先找出所有只写一次、却被多方读取的字段，再问每个消费方错了之后会怎样。语言标签、货币代码、地区码、时区，这四个字段基本都符合这个特征，而它们出问题的方式惊人地相似。

页面里那些英文片段，读屏软件会按哪门语言的规则念？

先承认一件事：小语种页面上一定有外语

纯粹只有一门语言的商业页面几乎不存在。

品牌名是外语，产品型号是拉丁字母加数字，技术规格里全是英文缩写。

支付方式、物流公司、社交平台的名字，也基本都保持原样。

这些片段不是翻译遗漏，它们本来就不该被翻译。

用户搜的也是这些原样的写法，把它们翻掉反而是错的。日语站上那层专门标读音的小字是另一种做法，它把读音写成了可见文本。

所以问题从来不是要不要有外语片段，而是这些片段被念出来的时候，机器该切换到哪一套发音规则。这个判断机器自己做不了，必须有人在页面上告诉它。

规范里专门为这件事留了一条

无障碍标准里有两条相邻的条款处理语言。

第一条管整页，要求页面的默认人类语言可以被程序确定，级别是最低的A级。

第二条管片段，要求页面里每一段跟主语言不同的文本，它的语言也可以被程序确定，级别是AA。

第二条的官方说明里写得很清楚，它的目的就是让辅助技术和浏览器能用正确的方式呈现这段文字。

换句话说，规范制定者早就想到了这件事，还专门给了它一个编号。

有意思的是它的例外条款：专有名词、技术术语、以及已经进入了周围语言日常用法的外来词，可以不标。这个例外看起来很宽，实际执行起来很窄，因为判断一个英文词有没有进入波兰语的日常用法，本身就是一个需要母语者拍板的问题。

为什么这一条在英语站上几乎不触发

英语页面上的非英语片段有多少？

一个法语菜名，一个德语术语，一句拉丁语引文，通常就这些。

一整个电商站扫下来，可能只有几处。

于是这条AA条款在英语站上的实际工作量接近于零。

做无障碍改造的人从来没觉得它是个负担。

而在一个泰语电商站上，同一条条款的工作量是每个商品标题里都有若干处。同一条规则，同一个级别，同一个验收标准，成本差了三个数量级。这是本站反复出现的那条账：合规预算是按站算的，工作量是按语言算的。

不标会念成什么

把一个英文词交给按波兰语规则工作的发音引擎，它不会拒绝。

它会用波兰语的字母读音规则把这串拉丁字母念出来。

结果是一个不存在的词，听上去既不像英语也不像波兰语。

越是常见的品牌名，被念坏之后越难认，因为用户脑子里有一个正确的读音在等着比对。

反过来，把波兰语词交给英语引擎，出来的是那位用户在邮件里描述的东西。

两个方向的坏法不一样。外语片段念错是局部噪声，用户能靠上下文猜回来；整页语言错是全局失真，每一个词都不对，上下文本身也是坏的，没有任何可以用来纠错的锚点。

非拉丁书写系统的站上，这件事更容易被量出来

希腊语、泰语、印地语、希伯来语、阿拉伯语的页面有一个便利之处。

只要页面上出现拉丁字母，那基本就是一段外语。

不像波兰语或德语页面，拉丁字母既可能是本地词也可能是英文，肉眼分不出来。

这意味着在非拉丁站上，外语片段的数量是可以直接数出来的。

保哥拿这个思路做了一次实测，数据在下一节。

顺带说一句，这也是做小语种技术审计时一个很好用的取巧办法：凡是能靠书写系统本身把两类内容分开的语言，很多问题都可以用一行正则量化，而不必先做语言识别。这类语言在做技术验证时反而比拉丁系语言省事。

三十二个站实测下来，语言片段标注究竟做到了几处？

这次实测是怎么做的

保哥挑了四十个真实站点，覆盖十六个市场。

一半是当地头部电商，一半是当地主流媒体和公共机构。

取每个站的首页HTML，只看四件事：文档最外层写的语言、页面内部出现了几次语言标注、书写方向、图片有没有替代文本。

四十个里有三十二个正常返回，其余是拒绝访问或者超时。

其中一个返回了状态码202加零字节的空响应，这是典型的反爬兜底，剔除。

所以有效样本是三十一个站。样本不大，也不是随机抽样，但是这三十一个站合起来是这些市场上最主流的一批页面，如果这批页面都是同一个结论，那这个结论至少描述了行业的现状而不是个别水平。

第一列数字：整页那一处，大家都写了

三十一个站，文档最外层的语言标签全部存在。

取值也都对得上市场：波兰站写波兰语，泰国站写泰语，罗马尼亚站写罗马尼亚语。

有几个写成了语言加地区的完整形式，比如德国那家建材站和越南那家手机零售站。

写成完整形式不算错，只是把地区信息一起声明了。

这一列的结论很清楚：最低那条A级要求，主流站点已经全部达标。

这其实是个好消息，也符合预期。这一处是所有页面体检工具都会检查的项目，是所有建站模板都会预留的位置，也是所有教程的第一课。凡是能被工具自动检出、又只需要改一次的事情，行业最终都会做到。

第二列数字：片段那一处，几乎全军覆没

三十一个站里，页面内部一次语言标注都没有的，有二十八个。

剩下三个站看起来有：一家匈牙利媒体标了九十三处，另一家匈牙利媒体标了四十四处，芬兰那家公共广播标了四十四处。

把这三个站的标注逐条打开看，结论要改。

那两家匈牙利媒体标的九十三处和四十四处，取值全部是匈牙利语，跟页面本身的语言一模一样。

那不是片段标注，那是内容管理系统给每一个条目自动加的冗余属性，标了等于没标。

所以真正意义上给非页面语言的片段做了标注的，三十一个站里只有一个。这个数字保哥自己看到的时候也停了一下，因为它已经不能叫做落实率低，它是一个接近于零的值。而这一条不是可选项，它写在AA级里，而AA是欧盟那套无障碍法规实际引用的级别。

唯一那个做到了的站，身份很说明问题

做到了的是芬兰的公共广播机构。

它的四十四处标注里，三十七处是芬兰语，另外七处分别是瑞典语、北萨米语、英语、俄语、乌克兰语、卡累利阿语、索马里语和阿拉伯语。

那是它的多语言服务入口，每一个语言链接上都带着自己的语言标注。

这意味着当读屏软件走到那一行时，它会切换到对应的发音引擎，把那个语言的名字用那门语言念出来。

这是唯一正确的做法，也是这三十一个站里唯一一次出现。

它是公共广播机构，是受无障碍法规约束最直接的那一类主体，也是唯一一个把这件事做完的。这个对应关系比数字本身更有信息量：这件事目前的驱动力是合规义务，不是产品意识。商业站点在同一批页面上的表现是零。

第三列数字：那些页面上到底有多少外语

光说没标不够，还得证明确实有东西需要标。

在书写系统本身就能区分的九个站上，保哥数了正文里拉丁字母词的比例。

最高的是泰国一家电子产品零售站，两千六百九十一个拉丁词，占正文词数的百分之四十一。

那些词是什么？是笔记本、平板、耳机、配件这些品类词和产品线名称，也就是用户下单前反复读的那一批。

最低的是一家俄语新闻站，百分之一点一，二十七个词。

中间这一段的分布是：泰国另外两家站分别是百分之十九点六和百分之十一点六，印地语那家是百分之十七点七，希腊两家是百分之五点一和百分之四点八，希伯来语和阿拉伯语两家是百分之四点九和百分之五点八。这九个站的内部语言标注全部是零，也就是说，从二十七个词到两千六百九十一个词，全都会被按页面语言念出来。

数字、货币和缩写被念成什么，凭什么也按语言分叉？

发音引擎干活的第一步不是发音

把一串字符变成声音，中间有一步经常被跳过不谈。

引擎要先把非文字的东西展开成词，然后才谈发音。

数字要展开成数词，货币符号要展开成货币名，缩写要展开成全称。

这一步叫文本规范化，它是完全依赖语言的。

同一个字符串，换一门语言展开出来的词完全不同。

这一层的存在感很低，因为在英语里它工作得太顺了。数字展开成英语数词，美元符号展开成dollars，都是一一对应的简单映射。而这个简单性不是普遍规律，它是英语的语法特性带来的巧合。

数字在屈折语里不是一个词，是一族词

波兰语里数量词后面跟的名词要按数量取不同的形态。

一件、两到四件、五件以上，分属三种不同的写法。

俄语和捷克语有类似的规则，具体分界线各不相同。

这意味着展开一个数字加名词的组合，引擎必须先算出该用哪一档。

算错了，念出来是一个母语者一听就别扭的搭配。

本站另有一篇讲过只有复数形态的那一批词在关键词表里的麻烦，那是文字侧的账。声音侧的账更直接：文字侧写错了用户可能看不出，因为他扫读时抓的是词干；声音侧念错了立刻就听得出来，因为韵律是连着的。

货币符号的读法各语言不一样

欧元符号在德语页面上念成Euro，位置在数字后面。

同一个符号在英语引擎那里念成euros，位置多半在数字前面。

更麻烦的是那些一符多义的写法，比如美元符号在不同市场指的不是同一种货币。

还有小数点和千分位这一对，两个地区正好写反，展开出来的数值可以差三个数量级。

价格是页面上最不能念错的一个数字。

而它恰好是整页里最依赖语言规则的一个字段，同时又最经常出现在没有语言标注的模板片段里，比如价格组件、比价表格、促销角标。这几处的共同点是：它们由代码拼出来，不经过翻译流程，也就没有人在那一步想起语言这件事。

缩写和单位是最容易被念成字母的一批

德语的举例缩写、法语的公司形式缩写、波兰语的街道缩写，各有各的展开规则。

发音引擎里带着这些规则，前提是它知道自己在念哪门语言。

语言标签一错，展开表就换了一本，缩写会被逐字母念出来。

单位符号同理，公斤、厘米、毫升在各语言里的读法不一样。

这一类内容在商品规格表里密度最高。

规格表还有一个特点：它通常是从数据源里渲染出来的，字段名和字段值分别来自不同的地方，很可能一个已经本地化了一个还没有。于是同一行文字里会出现两种语言，而这一行外面只有一个语言标注。

这一层为什么不能靠翻译流程解决

翻译流程处理的是词和句子。

数字、符号、缩写这些东西在译稿里通常原样保留，译者不会动。

母语审校也不会把它们标出来，因为在纸面上它们看着完全正常。

问题只在展开这一步才发生，而展开发生在用户的设备上，不在你的内容库里。

所以这不是一个翻译质量问题，是一个声明问题。

把语言声明写对，这一整层就自动正确了，一行代码解决几十种展开规则。把语言声明写错，你在译稿上下再多功夫也救不回来。这条投入产出比在本站的所有话题里都算极端的。

变音符号掉了之后，眼睛还能猜回来，耳朵为什么不能？

视觉这一侧的容错，来自读者本人

波兰语的带钩字母被写成不带钩的，母语者照样认得。

捷克语的软音符号掉了，读者也能靠上下文补回来。

越南语去掉声调，看着别扭但是能读。

这个容错能力不在你的系统里，它在人的脑子里。

所以文字侧的记号丢失，后果是观感变差和关键词匹配变差，不是不可读。

本站讲德语变音符号与关键词研究那一篇算的就是这笔账：用户输入时经常不打记号，所以词表两套写法都要覆盖。那是一个覆盖率问题，解法是往表里加行。

听觉这一侧没有这个容错

发音引擎不猜。

那个带钩的波兰语字母和不带钩的那个，读音完全不同，一个接近英语的w一个是普通的l。

记号掉了，引擎照着剩下的字母念，出来的是另一个词。

听的人没有办法像看的人那样回退去比对字形，声音是流过去的。

捷克语的软音符号、越南语的声调，情况相同甚至更严重，因为声调直接决定词义。

这里的不对称非常干净：眼睛可以回看，耳朵不能。视觉信息是空间上并存的，你能来回扫；听觉信息是时间上串行的，过去了就过去了。所有在视觉侧靠读者脑补兜住的问题，到了听觉侧都要重新算一遍，而且都会变严重。

具体到几门语言上差多少

波兰语丢记号的字母有七个，其中几个丢了之后读音变化最大。

捷克语和斯洛伐克语的长音记号影响的是音长，丢了之后词义可能翻转。

越南语的声调记号最极端，同一串字母配不同声调是完全不同的词，丢了声调等于把词打散。

希腊语的重音记号看起来只是个小撇，实际决定重音位置，念错了母语者会听成外国口音。

德语的变音字母有替代写法，两种写法读音相同，这一门反而最安全。

所以做多语言站的记号治理时，优先级不应该按语言的市场规模排，应该按记号丢失后的读音偏离程度排。越南语和泰语这类靠记号承载音位区别的语言必须排在最前面，德语这种有官方替代写法的可以往后放。这个排序跟按流量排出来的顺序几乎正好相反。

记号是在哪几步掉的

第一处是数据导入，编码不对就掉一批。

第二处是文件在不同电脑之间转手，地区设置会改写。

第三处是自动生成的字段，比如从标题派生的短描述，截断时正好切在组合字符中间。

第四处是第三方组件回填的内容，它们经常做一次自己的规范化。

第五处是搜索和排序功能里的折叠处理，本来是为了匹配，结果把折叠后的结果写回了展示层。

前四处本站都单独写过，第五处最隐蔽：折叠是为了让带记号和不带记号的查询都能匹配上，这个动作本身完全正确，错的是把折叠后的字符串当成了可以展示的内容。匹配层的产物不能进展示层，这条规矩在声音这一侧的代价比在文字侧大得多。

替代文本是页面上唯一一段只被念、不被看的字，它该按什么标准写？

先确认这句话是不是真的

页面上绝大多数文字，人和机器读的是同一份。

标题、正文、按钮，用户看得见，抓取程序也取得到。

图片的替代文本不一样，正常情况下没有一个用户会看到它。

它只在两种场合被消费：抓取程序取走，或者读屏软件念出来。

所以它是整页里唯一一段专门写给非视觉通道的文字。

这个定位本站在讲非拉丁站的图片文件名与替代文本那一篇里拆过六个位置各自的读者，那一篇算的是检索侧的账。这里补另一半：同一段字在声音侧的要求跟检索侧不完全一致，有几处甚至方向相反。

现有的写作规范全是按检索设计的

业内那些替代文本写作建议，来源基本一致。

写清楚图上有什么，带上关键词但别堆砌，长度控制在一百二十五个字符以内。

这三条都对，也都是从被检索这个用途推导出来的。

没有一条是从被念出来这个用途推导出来的。

而这两个用途对同一段文字的要求确实不一样。

检索侧要的是信息密度，词越准越好，语序无所谓，因为取词的程序不在乎你怎么组织句子。声音侧要的是可听懂，它必须是一个能顺下来的句子，语序和虚词都得在，否则听起来是一串关键词。

小语种上这个差别被放大了

屈折语里，一串没有语法连接的名词念出来会非常怪。

因为这些语言靠词尾表达关系，词尾一旦缺席，听的人拼不出这句话的结构。

英语在这一点上又一次天然占便宜，名词并列在英语里本来就是合法的表达。

所以照抄英语站的替代文本写法，在英语上是可接受的省略，在波兰语上是一段听不懂的碎片。

那一百二十五个字符的上限在这里同样要重算。

本站讲图片字段那一篇已经指出，同样字符数在不同语言里装的信息量差两三倍，非拉丁字形本身的成本也在同一条链路上。声音侧还要再加一条：听的人对长度的耐受度比看的人低得多，一段十五秒的替代文本会让人直接跳过。所以小语种站上的合理区间是两头夹的，下限被语法撑着，上限被听觉耐受压着。

装饰性图片那一条，只有在声音侧才讲得通

规范里说纯装饰的图片应该留空的替代文本。

很多人不理解为什么留空比随便写点什么好。

从检索侧看，留空确实是浪费了一个字段。

从声音侧看，留空是唯一正确的做法，因为它让读屏软件直接跳过。

不留空的话，用户要听完一串对他毫无意义的描述才能到达下一个有效内容。

一个商品列表页上有三十个装饰性图标，每个都念一遍，用户放弃这一页的概率接近百分之百。这也是为什么这条规则写得如此绝对：它保护的不是信息，是时间。

品牌名和型号在这一段里怎么处理

替代文本里出现品牌名和型号是常态。

它们在声音侧的问题跟正文里的外语片段完全一样。

要么给这一段套一个语言标注，要么接受它被按页面语言念出来。

但是这里有个现实约束：替代文本是属性值，你没法在属性值内部再嵌一层标注。

能标的最小单位是承载这个属性的那个元素本身。

所以真正可行的做法是把语言混排从替代文本里拿掉，让它尽量只用一门语言把图上的东西说清楚，把品牌名和型号留在图注或者周边正文里，那两个位置可以嵌标注。这条约束是标记语言的结构决定的，不是能靠写作技巧绕过去的。

后台那三类工具，为什么一条都查不出这件事？

自动化检查工具能测的是格式，不是正确性

无障碍自动化规则里，跟语言相关的有三条。

一条查文档最外层的语言标签是不是合法的语言标记。

一条查这个标签和它的另一种写法有没有对上。

一条查页面上任何带语言标注的元素，那个值是不是合法。

三条规则全部只验一件事：这个字符串在语言标记的注册表里存不存在。

没有一条能验它对不对。因为一个标签合不合法是可以查表判断的，而这一页实际上是什么语言，属于对内容的判断，自动化规则按设计就不做这类判断。这不是工具没做到，是它按定义就不该做。

把语言写成一个合法但错误的值，所有检查都是绿的

这是最要命的一点。

把波兰语页面标成英语，英语是合法标记，规则通过。

把希腊语页面标成希腊语的另一种历史写法，也是合法标记，规则通过。

把泰语页面标成泰语加一个不匹配的地区，仍然合法。

整条自动化链路上没有任何一环会说这不对。

而这三种写法在朗读时的表现分别是：整页换语言、可能落到错误的发音变体、多数情况没事。三种严重程度完全不同的错误，在报告里长得一模一样，都是没有问题。

页面体检工具与站长工具各自的盲区

页面体检工具读的是你发出去的源码。

它能告诉你这个属性有没有写，写的值是不是合法。

它不听声音，也没有发音引擎，所以它对结果一无所知。

站长工具那一侧连这个字段都没有，它关心的是收录和展现。

抓取诊断工具停在渲染这一步，渲染完就结束了，朗读发生在渲染之后。

三类工具的边界加起来，正好把这件事整个漏在外面。跟标题被替换那件事不同的是，那件事是工具里根本没有对应的字段；这件事是字段有、规则有、报告也有，只是所有规则按定义都测不到要害。后者更危险，因为它会给人一种已经检查过了的错觉。

那份自动化报告的通过率会误导决策

无障碍改造项目通常从自动化扫描开始。

扫描报告给出一个分数，团队按分数排优先级。

语言这一项因为格式都对，永远不会出现在待办列表里。

于是资源全部流向那些能被检出的项目，比如对比度和表单标签。

那些项目当然也重要，但是它们的严重程度未必比这一项高。

行业里有一份每年扫一百万个首页的公开报告，它统计的就是这类可自动检出的错误分布。这份报告有个必须理解的前提：它测的是能被自动测出来的那一部分，而这一部分跟真实体验受损的那一部分并不重合。把它当成行业现状的完整画像会推出错误的结论。

唯一能看到真相的地方是把耳朵接上去

这件事跟标题替换那件事有一个共同点。

所有在自己这一侧做的检查，都回答不了最终结果是什么。

唯一的办法是走到消费端，用消费端的方式消费一遍。

标题替换要去结果页上看，语言标注要用读屏软件听。

这两件事的成本都不高，难的是想到要做。

保哥这几年养成一个习惯，接手一个多语言站，先花二十分钟把三类页面听一遍。这二十分钟的信息量，通常比跑三份自动化报告还大，因为它是从用户那一侧取的证据，不是从你自己的源码里取的。

不懂这门语言，二十分钟怎么自己听出问题？

工具不用装，系统自带的就够

视窗系统自带讲述人，苹果系统自带旁白，安卓自
TalkBack。

桌面上还有一个免费的开源读屏软件，市场占有率很高，装起来只要几分钟。

这些工具的启动都是一组快捷键的事。

不需要学会用它做复杂操作，只需要让它从头念一页。

第一次开可能会被语速吓一跳，把语速调慢就好。

这一步的心理门槛远大于技术门槛。多数团队从来没打开过这类软件，不是因为难，是因为没人觉得这属于自己的工作范围。而它其实是这条链路上唯一的观测手段。

判据不是听懂，是听出这是哪门语言

你不需要懂波兰语。

你只需要判断：机器念出来的这一段，听起来像不像一门斯拉夫语言。

如果它听起来像一个英语母语者在念陌生单词，那语言标签就是错的。

这个判断不需要任何语言知识，普通人凭语感就能做。

把这一条写进验收清单，任何人都能执行。

这是整套办法里最关键的设计。凡是需要母语者才能执行的检查，都会因为排不到人而搁置；凡是不需要语言能力的检查，才有可能变成常规动作。所以判据要定在能不能听出语系这个粒度上，而不是定在念得准不准上。

要听的是哪三类页面

第一类是首页，它的模板最老，改动最多，语言标签最容易是历史遗留值。

第二类是商品详情页，它的外语片段密度最高，规格表和型号全在这里。

第三类是结账路径上的页面，因为这里出错的代价是订单。

三类各听两分钟，够了。

如果站上有多个语言版本，每个版本各抽一页。

抽样的重点不是覆盖率，是找出模板之间的差异。很多站的问题只出在某一套模板上，比如活动页用了另一套框架，那一套的语言标签停在出厂值。只听首页会漏掉这类问题，所以三类页面各听一遍比在一类页面上听十遍有用。

还要顺手记两件事

第一件是遇到英文片段时机器的表现。

它是切换了发音，还是用本地语言的规则硬念过去。

第二件是价格和数字被念成了什么。

这两处一旦不对，能顺藤摸瓜找到一批没有语言标注的模板组件。

把听到的异常记成一张两列的表：位置和现象。

这张表交给前端时不要写解决方案，只写现象。因为同一个现象可能有好几个成因，让实现那一侧去定位，比你隔着一层猜要快。这条在跨职能协作里通用，只是在这个话题上尤其明显，因为现象和成因之间隔着一整个发音引擎。

什么时候需要请母语者上场

前面那套办法能查出语言标签级别的错误。

查不出的是发音变体、重音位置、语调是否自然这一类。

这些需要母语者听，而且需要的是听力正常的母语者加上一次真实的读屏体验。

但是这一步应该排在后面，因为在语言标签还错着的时候请母语者来听，是浪费别人的时间。

先把确定性的错误修完，再去处理需要判断力的部分。

本站讲母语审校验收清单那一篇给过一个类似的顺序：能用规则判定的先跑规则，剩下的才交给人。声音这一侧同样适用，而且分界线更清楚，因为语言标签对不对是二值的，念得自不自然是连续的。

按位置分的语言标注清单，以及哪些不归语言层

第一档：必须标，标错代价最大

文档最外层那一处，写页面的主语言，这是底线。

语言切换菜单里的每一个选项，标它自己指向的那门语言。

整段的外语引文和外语说明块，比如英文的技术规格段落。

用户生成内容里能识别出语言的部分，比如另一门语言写的评论。

这四处的共同点是：内容长度足够，念错之后损失明确。

其中语言切换菜单是投入产出比最高的一处，因为它总共只有几行，而它恰好是那位听不懂当前页面的用户唯一的出路。把出路念坏，等于把门锁上。

第二档：值得标，成本可控

商品规格表里成段的英文字段。

合作品牌的宣传语这类原样保留的外语句子。

页面上嵌入的外语视频标题和说明。

这一档的判断标准是：它是不是一个完整的语言片段，而不是一两个词。

是的就标，不是就放过。

标注是有成本的，成本落在模板改造和内容录入流程上。所以要有一条明确的下限，否则这件事会变成给每个英文单词都套一层标签，那样既做不完也会把模板搞乱。

第三档：不必标，标了反而更糟

已经进入本地语言日常用法的外来词，规范里明确列为例外。

单个的品牌名和产品型号，属于专有名词，同样在例外里。

本地人已经按本地读音在念的那批词，标成外语会让它念得更陌生。

这一档要靠母语者拍板，因为它问的是这个词在这门语言里算不算本地词。

这个判断没有客观标准，也不该由英语母语的顾问来做。

把这三档写进内容规范时，第三档要给例子而不是给规则，因为规则写不清楚。列十个已经本土化的外来词当样板，比写一段定义有用得多。

怎么把它变成一个不会退化的流程

把文档最外层那一处做成模板变量，绑定当前语言版本，不许写死。

把语言切换菜单的标注做进组件，一次做完全站生效。

把第二档的标注做成编辑器里的一个按钮，让内容团队自己能加。

把二十分钟的听测写进模板改动的上线清单。

最后一条最重要，因为这一层最容易被一次改版打回原形。

本站在讲写死在代码里的界面文案那一篇里说过，凡是靠一次性改造达成的状态，都需要一道回归动作来维持。语言标注属于典型的一次做完、一次改版打回的东西，因为它藏在模板最外层，而模板最外层恰好是换框架时整块替换的部分。

哪些不归语言层，一句话交出去

键盘操作、焦点顺序、对比度、表单标签这些，属于通用的无障碍访问工程，跟语言无关。

页面的整体信息架构和标题层级，归内容结构那一层。

发音引擎本身的音质、语速、口音选择，归操作系统和辅助技术厂商。

多语言站的地址结构、互指标签的对称写法、地区定向，归国际化架构那一层。

搜索引擎怎么判断页面语言、判错了怎么修，本站另有专篇。

本篇只处理一件事：这一页上的字被机器念出来的时候，语言这一维有没有被正确地告诉机器。这一维是语言层的，其余的都不是。

常见问题解答

我们站的语言标签写的是对的，是不是就不用管这件事了？

整页那一处写对只解决了最低那一条，属于A级要求。片段那一条是AA级，实测三十一个主流站里只有一个做到。判断自己站上有没有欠账，最快的办法是数一下商品页上有多少个原样保留的外语词，再去源码里数有多少处语言标注。前者通常是几十，后者通常是零。

做无障碍改造是不是只跟视障用户有关，商业上划得来吗？

视障用户是最直接的受益方，但不是唯一的。语言标注还会影响浏览器的断词、日期与数字格式、默认字体选择，以及要不要弹出翻译提示。而在欧盟，这件事从2025年6月28日起对面向消费者的电商是法定要求，引用的标准
EN 301 549，它对应的正是AA级。这不是加分项。

把每一个英文单词都套上语言标注，是不是最保险？

不是，规范里明确给了例外：专有名词、技术术语、以及已经进入周围语言日常用法的外来词可以不标。全部套上会带来两个问题，模板复杂度失控，以及本地人已经按本地读音在念的词被强行切换成外语发音，反而更陌生。合理的下限是完整的语言片段，不是单个词。

用工具扫一遍能不能查出这类问题？

查不出要害。自动化规则里跟语言相关的三条，全部只验语言标记是不是合法值，没有一条能验它跟内容对不对得上。把波兰语页面标成英语，三条规则全部通过。这类错误的特征就是格式完全合法，所以在任何一份自动化报告里都是绿的。

我们用的是建站平台，模板改不了怎么办？

先确认它是真的改不了还是没找到入口。多数平台的语言设置在站点级别，改一次全站生效，问题往往出在多语言插件与主题模板各写了一份，两份不一致。如果确实动不了，优先保住两处：文档最外层的语言，以及语言切换菜单。这两处的收益占整件事的大半。

页面上的价格和数字被念错，跟语言标签是同一件事吗？

是同一件事的下游。发音引擎要先把数字、货币符号、缩写展开成词，这一步完全依赖语言，展开表跟着语言标签走。标签错了，整本展开表就换了，价格会被按另一门语言的规则念出来。所以这一层不需要单独治理，把标签写对就自动正确了。

这件事对搜索排名有没有直接影响？

直接的排名影响很弱，引擎判定页面语言时主要看可见内容，不会因为这个属性写错就把你降下去。真正的影响在两处：一是页面语言被判错时，你在对应语种检索里的可见度会掉，那是另一层的账；二是无障碍质量已经是很多市场的采购与合规门槛，那是订单层面的账。

权威参考资料