title属性在无障碍场景下基本不可信，因屏幕阅读器不主动读出、键盘用户无法触发、移动端完全失效；WCAG明确不推荐依赖它做关键提示，仅img、input、textarea、button、iframe等原生交互元素在特定前提下可有限使用，其中iframe的title是强制要求。
title属性在无障碍场景下基本不可信
它不会被屏幕阅读器主动读出，键盘用户无法触发，移动端完全失效——这不是浏览器 bug，而是规范设计使然。WCAG 明确不推荐依赖 title 做关键提示，尤其对表单、图标、非交互容器。
哪些元素加title还能凑合用
仅限原生具交互语义的元素，且必须满足“用户会自然 hover 或 focus”这一前提：
-
<img>：作为alt的补充信息（如版权说明），但不能替代alt -
<input>、<textarea>、<button>：仅当无更好方案时作 fallback，比如旧版 IE 中日期输入框格式提示 -
<iframe>：必须写title，否则屏幕阅读器报“内嵌框架,无描述”，这是 WCAG 2.1 强制要求
所有其他元素（<div>、<span>、<svg>）加 title 都属于“看起来有效，实则不可靠”的伪方案。
真正能过无障碍审计的替代方案
核心逻辑是：让提示文本既可被屏幕阅读器读出，又能在视觉上呈现，且支持键盘焦点和触控操作。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 表单控件用
aria-describedby关联外部<div id="hint">，同时该<div>用 CSS 控制显隐 - 图标按钮用
role="button"+tabindex="0"+aria-label，再用::after渲染视觉 tooltip - 动态提示（如校验失败）用
aria-live="polite"区域，配合setCustomValidity()触发
不要试图用 title + aria-label 双写——读屏器会重复朗读，反而干扰用户。
iframe 的 title 属性是唯一不能省的例外
它不是“可选优化”，而是强制可访问性门槛。漏掉会导致视障用户完全不知道这个区域存在什么内容。
- 值必须描述功能与上下文，例如
title="用户对文章《前端性能优化实践》的评论" - 避免技术路径或组件名，长度控制在 100 字符内
- 动态插入的
<iframe>必须在 JS 中手动设置el.title = "xxx"，模板里写的没用 - 若 iframe 内容页本身有
<title>标签，外部title会被忽略，此时需改用aria-label覆盖
其他所有地方的 title 都该视为临时补丁，而不是设计起点。真正的无障碍提示，得从 DOM 结构和 ARIA 语义出发，而不是等浏览器自动弹个小黄框。
