ARIA 标签 (aria-label) 是 W3C 的 WAI (Web Accessibility Initiative) 制定的 WAI-ARIA (Accessible Rich Internet Applications) 规范中定义的属性，为 UI 元素提供无障碍名称。它用于为没有视觉标签的元素提供文本信息，是屏幕阅读器朗读该元素时的依据。

aria-label 特别有效的场景，是纯图标按钮、导航地标这类视觉上通过设计就能传达含义、但缺少文本信息的元素。例如搜索按钮上只放了一个放大镜图标时，添加 aria-label="搜索" 就能让屏幕阅读器用户也了解按钮的用途。同样，当页面中存在多个 <nav> 元素时，可以用 aria-label="主导航" 和 aria-label="页脚导航" 加以区分。

相关属性还有 aria-labelledby (引用其他元素的文本) 和 aria-describedby (引用补充说明)。aria-label 是直接在元素上指定文本，而 aria-labelledby 是引用已有元素的 ID 来获取名称。一般的分工是：页面上已经存在合适的文本时优先用 aria-labelledby，不存在这类文本时才用 aria-label。若在同一个元素上同时写两者，aria-labelledby 会优先生效，因此应避免并写。操作方法、注意事项这类补充信息不要塞进 aria-label，而应作为可见文本放出来，再用 aria-describedby 关联起来。这些说明不只是屏幕阅读器用户需要，而是所有人都需要的信息。

实务中最常见的事故，是 aria-label 覆盖了已有的标签。一旦写了 aria-label，它的值就会优先于该元素的 <label> 元素文本、图片的 alt 属性、iframe 的 title 属性，被采用为无障碍名称。如果这里写的文案与画面上显示的标签不一致，就违反了 WCAG 的成功标准 2.5.3"名称中包含标签"(符合级别 A)。该标准要求：对于标签中含有文本或文本图像的 UI 组件，名称中必须包含视觉上呈现出来的那段文本。给画面上显示"提交"的按钮加上 aria-label="保存表单"，使用语音识别操作的用户即使说出"提交"也不会有任何反应。与可见标签不同的名称，还可能变成被意外触发的隐藏命令。

另一个陷阱，是把 aria-label 加在它根本不起作用的元素上。aria-label 只在允许作者提供名称的角色上有效，实际能生效的是链接、表单控件、小部件、地标、图片、iframe 等。没有指定 role 的 <span> 和 <div> 会被归入 generic 角色，而该角色禁止命名。code、emphasis、strong、paragraph、presentation 等角色同样如此，写在这些元素上的 aria-label 不会传递给辅助技术，只会被白白放置。

更根本地说，ARIA 的使用应限定在原生 HTML 的标签方式 (<label> 元素、alt 属性、<button> 的文本内容等) 不足够的场合。W3C 的"Using ARIA"给出的第一条规则是：如果有一个原生的 HTML 元素或属性，本身就内置了所需的语义与行为，那就直接使用它，而不要挪用其他元素再补上 ARIA 的 role、状态和属性。第二条规则是"除非确有必要，不要改变原生语义"。过度使用 ARIA 反而会损害无障碍性，并可能以预料之外的方式改变屏幕阅读器的行为。

从字符计数的角度看，aria-label 的文本不会显示在画面上，但屏幕阅读器一旦到达该元素就会把它一口气读完。规范中并没有词数或字数的上限。判断标准是"是否用最短的表达把该元素的用途讲清楚"。按钮用表示动作的词，如"搜索""关闭"；导航则补上能与其他导航区分开的词，如"主导航"。当列表中反复出现"查看详情"时，可以写成 aria-label="查看详情 (产品 A)"，只补上区分所必需的词。把画面上显示的文本放在开头、区分用的词接在后面，这样也能与语音输入的调用方式保持一致。反过来说，超过一句话的说明或一串符号只会加重朗读负担，作为名称并不起作用。