F4.10.5untruncated accessible name设计
截断后的文本仍需在辅助技术中可读取完整内容
别名: 屏幕阅读器读到省略 · accessible name · 可见文本与无障碍名
概念解释
屏幕上的省略和辅助技术里的名字是两套东西。绘制可以把后半截藏起来；无障碍名称（accessible name）若跟着可见残句走，屏幕阅读器就会把「项目建议…」读成整条标题。看不见屏幕的人没有「靠残句猜」这条路，他们需要源字符串。视觉层可以压缩，名称计算必须拿到未被裁过的值。
机制
平台把「画出来的字」和「辅助功能树里的名字」分开算。有的原生标签在行打断截断时仍向阅读器暴露全文；Web 上一旦有人把节点的文本改写成带省略号的短句，源就没了。用溢出省略只裁绘制、不改文本节点时，名字计算通常还能拿到全文——除非 aria-label 被设成了可见的那截，或者列表虚拟化只把可见子串挂上去。画布里描出来的字更糟：辅助树里常常根本没有这串文本。读屏用户也无法使用悬停气泡当入口，因为焦点根本进不去那个气泡。所以「视觉上裁、名称上完整」必须是显式的数据流，不能指望绘制行为自动同步。
边界
后端如果只返回了二十个字，辅助技术救不回没传来的部分——那是数据截断，不是绘制截断。口令、证件号、被打码的字段不该被完整读出。上千字的描述整段朗读会变成负担，这时短名称加上一个阅读器能激活的「展开」才合理。仅把省略号画在伪元素上、文本节点仍是全文，对阅读器通常已经够；真正的失败集中在字符串被改写、被画布化、或无障碍名被设成残句这三种。
怎么落地
- 省略只发生在绘制，不要把「…」写进字符串，也不要用残句去覆盖无障碍名。
- 用无障碍检查器对照三列：源字符串、可见文本、计算得到的名称。名称必须等于源，而不是等于带省略号的可见文本。
- 用一种屏幕阅读器走过所有带省略的列表项，听它读出的是不是全文；读到「省略」两个字或听到残句，就说明名称被画层污染了。