外部资源链接本身不承担可访问性告知义务，真正需明确告知的是改变用户上下文、触发下载或绕过当前页面交互的行为；link元素无需aria-label或title，因其属后台增强、不可见不可交互；a标签指向PDF等文件时必须声明格式与大小；target="_blank"需配合上下文提示而非仅rel属性；rel语义链接一般无需处理，除非链接文本本身缺乏语义。
外部资源链接本身不承担可访问性告知义务，真正需要明确告知的，是那些会改变用户上下文、触发下载、或绕过当前页面交互流程的行为。
为什么 link 元素不需要 aria-label 或 title
浏览器自动加载的 <link rel="stylesheet">、<link rel="icon"> 这类外部资源，对用户不可见、不可交互，也不影响焦点流或屏幕阅读器播报顺序。它们属于“后台增强”，不是导航动作。强行加 aria-label 不仅无效，还可能干扰辅助技术解析——比如某些读屏软件会误报“已加载样式表”，造成冗余噪音。
- 规范依据来自 HTML5.3：这类链接归类为“外部资源链接”，语义上不暴露给用户
- 真实风险点不在
link本身，而在它引用的资源是否可访问（例如 CSS 中的 color contrast、icon font 的语义缺失） - 如果用了
<link rel="prefetch">，也无需告知用户——这是性能优化指令，不是用户操作结果
a 标签指向 PDF/Word/Excel 时必须主动声明
当 <a href="report.pdf" download> 或 <a href="manual.docx"> 这类链接被点击，用户实际离开当前网页上下文，进入一个外部应用（如 Adobe Reader、Office），此时无障碍体验完全脱离开发者控制。W3C WCAG 2.1 明确要求：必须在链接文本或 aria-label 中说明资源类型与大小。
- 错误写法：
<a href="annual.pdf">年度报告</a>—— 屏幕阅读器只读“年度报告”，用户不知将打开 PDF - 正确写法：
<a href="annual.pdf" aria-label="年度报告（PDF，2.4 MB）">年度报告</a> - 更优实践：把格式和大小放进链接文本本身，避免依赖 ARIA（因部分旧读屏不支持
aria-label覆盖）
target="_blank" 必须配 rel="noopener noreferrer"，但不是可访问性义务
这个组合解决的是安全漏洞（防止新页面通过 window.opener 控制原页面），不是可访问性问题。真正影响可访问性的，是缺少上下文提示：用户不知道点击后会新开标签页，可能误以为原页面已跳转。
立即学习“前端免费学习笔记（深入）”；
- 单纯加
rel="noopener noreferrer"不解决可访问性，必须配合视觉或语义提示 - 推荐做法：在链接文本后加统一图标（用
<span aria-hidden="true">↗</span>）+aria-label补充说明，例如：<a href="blog.html" target="_blank" rel="noopener noreferrer" aria-label="博客文章（在新标签页打开）">阅读更多<span aria-hidden="true">↗</span></a> - 注意：iOS Safari 对
target="_blank"处理特殊，有时会强制全屏弹窗，测试时务必真机验证
rel="license" 或 rel="author" 这类语义链接要不要可访问性处理？
不需要额外处理。这些 rel 值描述的是文档间关系，不是用户操作目标。屏幕阅读器不会播报它们，搜索引擎也不会因此调整权重逻辑。但有一个例外：
- 如果
<a rel="license" href="cc-by-4.0.txt">知识共享协议</a>是页面底部唯一可见的链接，且文本模糊（如只写“协议”），那就违反了可访问性原则——不是因为rel值，而是因为链接文本缺乏语义 - 应改为：
<a rel="license" href="cc-by-4.0.txt">本内容采用知识共享署名 4.0 国际许可协议授权</a> - 所有
rel值都只是元数据，真正决定可访问性的，永远是href是否有效、text content是否自解释、是否与上下文形成合理认知闭环
最容易被忽略的点：可访问性告知不是往标签里堆属性，而是判断“用户此刻最需要知道什么”。PDF 链接要讲格式和大小，新窗口链接要讲行为变化，而 <link> 引入的字体或样式表——用户根本不需要知道它存在。
