Listbox选项里的标题为什么可能只成为名称的一部分

一个列表选项里排了标题、说明和按钮，是否就表示读屏用户会依次获得同样的结构？W3C的ARIA Authoring Practices Guide在Listbox Pattern中先说明，选项名称是浏览器计算出的字符串，通常来自选项内容。这个名称是扁平的，不包含内容内部的语义信息。

Listbox首先是一组可供选择的选项，可以允许单选或多选。APG说，读屏呈现它时，可能读出选项的名称、状态与位置。这里的名称不是一份保留全部内部结构的小型文档。若选项中包含标题元素，读屏用户并不能从这个扁平名称获得它原来的标题语义。标题文字可能参与名称，标题身份却是另一个问题。

这种区别不只是显示风格。一个词在画面上更大、更粗，说明视觉设计强调了它；按文档所述，选项名称仍作为字符串被理解，不能仅由视觉强调推断它具备可供读屏导航的标题结构。本文只解释APG所述关系，没有检查实际页面或把某个浏览器结果写成普遍实测。

内嵌交互也有单独限制。APG说，listbox角色向辅助技术表达的交互模型，不支持与选项内部元素进行交互，因此它不适合承载链接、按钮或复选框这样的交互元素清单。原页为这类需要指向另一种Grid模式。本文没有采用该链接后的完整规范，也不提供把控件替换成另一种实现的代码。

即使选项只有文字，名称怎样组成仍值得读清。文档将整个名称描述为一次完整的语音单元：内容过长时，理解会变难；语音被打断后，用户通常还要重新听整项。于是，一段在视觉上能够快速扫过的说明，并不必然在一次听读中具有相同成本。这里采用的是指南的解释，不是本文做过计时实验。

重复前缀又会把差别放到名称末端。原文以选择城市为例：如果每个城市前都先写国家名，同一国家下许多选项便会在城市名出现前反复读出国家。读者要等待共有部分结束，才听到真正区分选项的内容。这个例子说明信息在名称中的先后关系，不能据此给任意真实列表直接下达修改结论。

本篇只采用Listbox的About This Pattern及相邻示例说明，首次发布日期未知。它不同于标签页获得焦点是否激活，也不是combobox允许输入哪些值的问题。选项文字、内部语义与可交互元素需要分别理解，不能让一张内容丰富的视觉稿，代替对控件所表达关系的说明；这仍不构成整站无障碍认证。