必须加在实际接收文本输入的容器上，且该容器需设role="textbox"；例如<div contenteditable="true" role="textbox" aria-multiline="true">，而非textarea或input[type="text"]。
aria-multiline="true"该加在哪个元素上
必须加在实际接收文本输入的容器上，且该容器得是 role="textbox"。不是加在 textarea 上——它原生支持多行，不需要额外标；而是加在用 div、span 等模拟编辑器的富文本区域上。
常见错误是直接给 textarea 加 aria-multiline：它会被忽略，因为浏览器已知 textarea 天然多行，加了反而可能干扰辅助技术判断。
- 正确做法：
<div contenteditable="true" role="textbox" aria-multiline="true"></div> - 如果用了
textarea，删掉aria-multiline—— 它冗余且不必要 - 若容器是
input type="text"，别加aria-multiline="true"—— 它物理上不支持多行，标了会误导屏幕阅读器
为什么不能只靠 aria-multiline 判断是否多行
aria-multiline 是“声明”，不是“实现”。它告诉辅助技术“这里允许多行输入”，但不改变 DOM 行为或样式。用户按 Enter 是否换行、内容是否滚动、能否粘贴多行文本，全靠底层元素能力支撑。
比如一个 div[contenteditable] 加了 aria-multiline="true"，但没处理 Enter 键事件，默认会插入 <div></div> 或触发浏览器默认行为（可能跳到下个焦点），结果就是“声明多行，实际单行”。
立即学习“前端免费学习笔记（深入）”；
- 必须配套监听
keydown拦截Enter，并手动插入<br>或\n - 要设
white-space: pre-wrap或pre-line才能让换行符渲染出来 - 需用
tabindex="0"让元素可聚焦，否则role="textbox"无效
textarea 不用 aria-multiline，但 name 和 label 很关键
textarea 原生支持多行，所以 aria-multiline 属于画蛇添足。真正影响无障碍体验的是 name 和关联的 label。
屏幕阅读器读 textarea 时，会播报“某某字段，多行文本框”，这个“多行”来自其语义，不是来自 ARIA 属性。
- 必须配
<label for="id">描述</label>+<textarea id="id"></textarea>，否则无法建立语义关联 -
name属性缺失会导致表单提交时字段名为空，后端收不到数据 - 如果用
aria-label替代label，虽能读出文字，但失去可点击聚焦能力，降低可用性
容易被忽略的兼容性细节
某些旧版 NVDA 或 JAWS 在遇到 contenteditable + aria-multiline="true" 时，仍会把 Enter 当作表单提交键，除非明确阻止默认行为并重发事件。
更稳妥的做法是：在 keydown 中对 Enter 调用 event.preventDefault()，再用 document.execCommand('insertLineBreak')（已废弃但仍有兼容性）或插入 <br>，最后手动移动光标。
- 不要依赖
white-space: pre—— 它会让空格和缩进全部保留，破坏排版 - 移动端 Safari 对
contenteditable的aria-multiline支持不稳定，建议优先用原生textarea - 若必须用自定义编辑器，至少提供降级方案：检测到不支持时，回退到隐藏
textarea+ 同步内容
