aria-readonly用法及注意事项详解

在HTML中，`aria-readonly`并非功能开关，而是一份专为屏幕阅读器等辅助技术撰写的“语义说明书”，它仅传达“此内容不可编辑”的意图，却完全不阻止用户输入、粘贴或修改——若脱离原生`readonly`属性或JavaScript事件拦截，就会导致界面行为与无障碍提示严重割裂；因此，真正可靠的只读体验必须坚持“行为控制（如`readonly`或`contenteditable="false"`）+ 语义同步（`aria-readonly="true"`）+ 后端校验”三层协同，尤其在自定义组件和动态状态切换场景中，忽视这一原则不仅削弱可访问性，更可能让残障用户陷入困惑甚至操作失败。

aria-readonly 不是替代 readonly 的属性

aria-readonly 是 ARIA 规范中用于辅助技术（如屏幕阅读器）传达“只读”语义的属性，但它**不改变任何交互行为**。浏览器不会因此阻止输入、禁用聚焦或影响表单提交逻辑。它只负责告诉辅助工具：“这个字段当前不可编辑”。如果你没加原生 readonly 或没拦截事件，用户照常能输、能粘贴、能删——而屏幕阅读器却在说“只读”，这就造成语义与行为严重错位。

什么时候必须配对使用 aria-readonly 和 readonly

典型场景是自定义组件：比如用 div + contenteditable="false" 模拟输入框，或富文本编辑器（TinyMCE/CKEditor）切换只读模式时。这些元素没有原生 readonly 属性支持，但需让 NVDA、JAWS、VoiceOver 正确识别状态。

• 原生 <input type="text"> 或 <textarea>：直接用 readonly 即可，aria-readonly 属于冗余，除非你动态切换状态且需显式同步
• 非表单元素（如
  ）：必须设 contenteditable="false" + aria-readonly="true"，否则辅助工具可能默认当作可编辑
• React/Vue 中通过 props 控制只读态：JS 设置 element.readOnly = true 后，应同步调用 el.setAttribute('aria-readonly', 'true')，否则 SSR 与客户端 hydration 可能不一致

常见错误：把 aria-readonly 当成样式或功能开关

以下写法完全无效：

<input type="text" value="订单号" aria-readonly="true">
<div contenteditable="true" aria-readonly="true">这段文字还是能编辑</div>

原因很直接：aria-readonly 不触发任何 DOM 行为约束。它只是个“说明标签”。容易踩的坑包括：

• 仅加 aria-readonly="true" 却漏掉 readonly 或事件拦截 → 用户可随意修改，无障碍体验反而更差
• 在 disabled 元素上再加 aria-readonly="true" → 冲突：disabled 已隐含“不可编辑”，ARIA 层叠会引发屏幕阅读器误读
• 用 aria-readonly="false" 声明“可编辑”，但实际没放开 readonly → 辅助工具被误导，认为能输而实际不能

生产环境建议：优先用原生 readonly，aria-readonly 仅作补充

真正需要关注的是语义对齐和降级兼容：

• 对原生表单控件，始终以 readonly 为事实来源，aria-readonly 仅在 JS 动态切换时做同步（例如 el.readOnly = isLocked; el.setAttribute('aria-readonly', isLocked.toString())）
• 配合 aria-label 明确内容意图，比如 aria-label="系统生成编号：ABC-2024-001"，避免依赖 placeholder 或 value 让屏幕阅读器猜测
• 测试时务必用真实辅助工具验证：NVDA + Chrome、VoiceOver + Safari，看是否朗读完整内容且不附加冗余提示（如“只读”后缀）

最易被忽略的一点：即使所有 HTML 和 ARIA 都写对了，如果后端没做校验，用户仍可通过 DevTools 直接删掉 readonly 属性并提交——aria-readonly 连这层防护都没有，它纯粹是给辅助技术看的“说明书”。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《aria-readonly用法及注意事项详解》文章吧，也可关注golang学习网公众号了解相关技术文章。