rel="help" 仅具语义提示作用，对残障用户无效；真正有效的帮助需通过 aria-describedby 等 aria 属性关联可见、上下文相关的帮助文本，并确保其可访问、可聚焦、术语一致。
rel="help" 的实际作用非常有限
rel="help" 是 HTML 中一个合法但几乎被所有主流辅助技术（如屏幕阅读器）忽略的链接关系。它不会自动触发帮助提示，也不会让当前页面“关联”到无障碍帮助指南——它只是语义上暗示这个链接指向某种帮助资源，仅此而已。
- 浏览器不会为
rel="help"添加特殊 UI（比如问号图标或悬浮提示） - 屏幕阅读器通常不播报
rel值，更不会据此改变导航行为或朗读上下文 - WCAG 和 ARIA 规范中未将
rel="help"列为无障碍支持机制
所以，单纯写 <link rel="help" href="help.html"> 或 @#@#@#@#@#@#@#@#@#@0，对残障用户几乎零帮助效果。
真正起作用的是 aria-labelledby + visible help trigger
要让当前页面可访问地关联帮助指南，关键是让用户能主动、明确地找到并理解帮助内容的用途。推荐做法是：
- 在需要解释的控件旁（比如表单字段）放置一个可见的
?或“帮助”按钮 - 用
aria-labelledby或aria-describedby将该控件与帮助文本建立程序化关联 - 帮助文本必须在 DOM 中存在（不能仅靠
href跳转），且默认可见或可通过焦点访问
<label for="zip">邮政编码</label> <input id="zip" name="zip" aria-describedby="zip-help"><div id="zip-help" role="note">请输入 6 位数字，例如 100000</div>
-
role="note"比role="alert"更合适，避免打断用户流程 - 不要用
title属性替代——它不可键盘访问，且屏幕阅读器支持不稳定 - 如果帮助内容是弹出式，确保它获得焦点、有
aria-modal="true"和关闭机制
link[rel=help] 只适合做全局帮助入口，且需额外标注
如果你坚持用 <link rel="help" href="accessibility-help.html">（比如放在 中），它唯一合理的作用是：为开发者或自动化工具（如 Lighthouse、axe）提供线索，说明站点存在帮助文档。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
但对终端用户无效，除非你同时：
- 在页面显眼位置（如页脚或顶部导航）添加一个可见的“无障碍帮助”链接
- 该链接的文本明确，例如
@#@#@#@#@#@#@#@#@#@1 - 页面
accessibility-help.html本身符合 WCAG，支持键盘导航、足够对比度、结构化标题
注意：rel="help" 的 href 必须指向真实可访问的 HTML 页面，不能是 PDF 或纯图片——否则对视障用户等于不存在。
容易被忽略的细节：帮助内容必须上下文相关
很多团队把“帮助”做成通用 FAQ 页面，结果用户点击后找不到当前表单或控件的具体说明。真正的无障碍帮助必须：
- 与当前页面功能强绑定（例如“登录页的帮助”不能跳转到“产品总览帮助”）
- 使用相同术语：如果界面上叫“验证码”，帮助里就不能写“校验码”
- 支持快速定位：用锚点或
fragment直达对应章节，比如help.html#password-rules - 提供多种形式：文字说明 + 简短视频（带字幕）+ 键盘操作演示 GIF（需配文字描述）
没有上下文的“帮助”，不是帮助，是障碍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
