E1.16.2screen reader announces role设计研究
屏幕阅读器会分别播报链接与按钮的角色而非仅读文案
别名: 播报角色 · link button utterance · role announcement
概念解释
屏幕阅读器对一枚控件的完整句子是名称 + 角色（再加状态）：「保存，按钮」「个人资料，链接」。用户靠角色决定下一步策略：链接就准备导航、也许开转子跳链接；按钮就准备激活、也许去按钮列表找。只把文案读对而角色错或缺失，等于给了正确的名词、错误的动词。分别播报角色，不是锦上添花，是分类查找能成立的前提。
机制
熟练的阅读器用户很少线性听完整页，他们用转子、快捷键按角色跳。角色一旦是「组」或「文本」，这条对象从跳转表里消失，即使名称里写着保存。角色是按钮而实际会导航，用户不会用开新标签的命令；角色是链接而实际会提交，用户可能把它留给稍后批量打开，结果提前提交。名称相同的两枚控件（都叫「下一步」）全靠角色区分导航下一步和提交下一步。可见外观帮不了这条通道。合成语音把角色读在名称后，用户是在听完角色才拍板，所以角色错误会直接改写决策。
怎么研究
在阅读器里列出本页所有按钮、所有链接，看目标控件在不在正确的表里。再听线性聚焦的完整句子。对照角色正确、角色缺失、角色相反。
自变量：DOM 角色、名称是否相同、用户是否使用转子。 因变量：能否用角色跳转到目标、决策是否与真后果一致、完成时间。
让视力正常的主试看着屏幕听，会用眼睛补角色。应遮住屏幕或请盲人用户来做分类查找。
边界
有的阅读器可以关掉角色播报，用户若关了，名称必须自足，但不能把产品建立在「用户关了角色」上。图标按钮名称若已写成「保存按钮」，会和角色叠成「保存按钮，按钮」。PDF 阅读器的角色支持参差，同一套 DOM 假设搬不过去。
怎么落地
- 保证导航出现在链接表、动作出现在按钮表，而不是只检查线性朗读有没有字。
- 名称不要包含「按钮」「链接」字样，把角色留给阅读器。
- 同一文案用于两种角色时，必须靠角色区分，并在任务里分别可被跳到。
- 验证：打开转子的按钮列表与链接列表。保存应只在按钮里，个人资料应只在链接里。两表都没有或都有，角色就没有被分别播报。