可通过语音选中的元素必须具有与视觉标签一致的可访问名称
别名: 标签包含于名称 · 可见标签与名称 · Label in Name
概念解释
语音用户看着屏幕说自己看见的词。控件要被这句话选中，可访问名称（accessible name）必须包含那串可见标签。按钮写「发送」，名称却是 submitBtn 或「提交表单」，人说「点击发送」会对空。这是界面给语音通道的合同：看见的字就是可以说的字，不是辅助技术内部如何做字符串匹配的说明书。
机制
发指令的人用视觉规划话语，系统用名称做匹配。两条字符串若对不上，失败发生在选中这一步，功能其实还在。常见错位：可见标签写给营销（「马上开始」），名称写给代码或屏幕阅读器（「创建账户」）；图标旁的字被 CSS 藏掉，名称还留着旧文案；动态改了按钮上的字，名称没跟上。
「包含」允许名称比可见标签长（可见「发送」，名称「发送邮件」），因为用户说出的子串仍能命中。反过来不成立：可见「发送邮件」、名称只有「发送」，用户按看见的整句说，可能匹配失败。可见标签被拆成装饰性字符、中间插入图标字体，名称若原样拼进去，人口语里也不会那样念。
怎么研究
打开系统语音控制（macOS / iOS Voice Control、Android Voice Access），对每个带可见文字的控件朗读那个文字，看是否命中。再故意说代码名、aria 名，看是否只有开发者知道的词能中。
自变量：可见标签与名称是否为包含关系、是否有隐藏的旧文案。 因变量：按可见词的命中率、用户改口次数、是否被迫改用编号或网格。
自动化可抓可见文本与 accessible name 做包含检查，但仍要用真语音跑一遍：合成匹配规则和系统语音控制并不总一致。
边界
没有可见文字的控件不走这条合同，问题变成「根本没有可说的词」。多个控件可见标签相同，即使名称一致，仍消歧不了。语音关闭、用户改用指针时，名称不一致仍伤害屏幕阅读器，但那是另一条验收。不要把名称计算的优先级表当成可选中性本身——计算错了会表现为名称不一致，判据仍是「说出看见的词能否选中」。
怎么落地
- 让可见标签成为名称的一部分：按钮上写什么，名称就含什么；改文案时两处一起改。
- 不要用不可见的「更专业」名称覆盖可见词；需要补充说明就加在可见词后面，而不是替换。
- 验证：对每个带文字的动作控件说「点击 + 看见的字」。失败的每一处记下可见词和实际名称，修到说出可见词能中为止。