aria-readonly仅影响屏幕阅读器播报，不阻止交互；disabled则全面禁用交互并自动添加aria-disabled；readonly需手动配aria-readonly才能实现无障碍只读，且仅适用于支持readonly的元素。
aria-readonly只改屏幕阅读器播报，不锁交互
aria-readonly 是纯语义层标记，浏览器和表单逻辑完全无视它。它既不会阻止用户输入、点击或聚焦，也不会影响复制、选中或提交行为——input 依然可编辑，值照常进 FormData。唯一作用是让屏幕阅读器读作“邮箱，只读，example@domain.com”。如果你没同时加原生 readonly 或 disabled，那 aria-readonly="true" 就只是个“听得到但拦不住”的提示。
disabled 才真正切断所有通道并影响无障碍
disabled 是原生属性，生效即触发三重封锁：视觉上灰显 + 交互上禁焦点/禁点击/禁键盘输入 + 提交时剔除字段。更重要的是，浏览器会自动给它加上 aria-disabled="true"，屏幕阅读器明确播报“已禁用”，且跳过该元素的导航顺序。这对依赖键盘或读屏器的用户是关键保障——他们不会误入一个“看起来能点但实际卡死”的控件。
readonly 属性本身不带无障碍语义，必须手动补 aria-readonly
原生 readonly 只控制行为（可聚焦、可复制、值提交），但不声明语义。屏幕阅读器默认把它当普通输入框读，用户可能误以为能编辑。所以当你用 readonly 时，必须同步写 aria-readonly="true"，否则无障碍体验就断了。注意：这个组合只对 <input type="text">、<textarea></textarea> 等支持 readonly 的元素有效；对 <select></select> 或 <button></button> 加 aria-readonly 没意义，因为它们根本不走这条语义路径。
别混用 disabled 和 aria-readonly，后者会被覆盖
如果一个元素同时有 disabled 和 aria-readonly="true"，屏幕阅读器优先响应 aria-disabled="true"（由 disabled 自动注入），aria-readonly 彻底失效。更麻烦的是，开发者可能误以为“我写了 aria-readonly，所以它只是只读”，结果实际是彻底禁用——表单提交丢值、键盘无法聚焦、样式不可逆。这种错配在动态 JS 控制时尤其容易发生，比如用 el.setAttribute('aria-readonly', 'true') 却忘了清除旧的 disabled。
最易被忽略的点是：只读 ≠ 无障碍只读。你加了 readonly，不代表屏幕阅读器知道它是只读的；你加了 aria-readonly，也不代表用户真不能改它。两者必须按需配对，且严格区分适用控件类型。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
