如何利用HTML的aria-readonly标注内容可见但不可编辑的表单字段状态-html教程-PHP中文网

aria-readonly仅向辅助技术传达只读语义，不改变交互行为；必须与原生readonly或事件拦截配合使用，否则会导致语义与实际行为错位。

如何利用html的aria-readonly标注内容可见但不可编辑的表单字段状态

aria-readonly 不是替代 readonly 的属性

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

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

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

原生或：直接用 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 行为约束。它只是个“说明标签”。容易踩的坑包括：

											
												
												
													生成HTML格式PPT
													从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
												
												下载
												
											
										

仅加 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 连这层防护都没有，它纯粹是给辅助技术看的“说明书”。