role属性唯一作用是告知屏幕阅读器元素的语义角色，仅在原生HTML无法准确表达时才需使用；滥用、冗余或错误设置会破坏无障碍体验。
开发圈子里有种误解，以为role属性能“增强样式”或是“方便Ja vaScript查找元素”。其实不然，这个属性的使命非常纯粹：它仅仅是告诉屏幕阅读器——“这个元素在语义上到底扮演什么角色”。一旦用错、滥用，甚至用它去覆盖原生元素的语义，结果往往适得其反，直接破坏了网站的无障碍体验。
什么时候必须用 role 属性
那么，究竟什么时候才该请出role属性呢？答案很明确：只有当现有的HTML原生标签，实在无法准确表达你当前组件的真实语义时。比如下面这些典型场景：
- 你用
标签搭建了一个下拉菜单的容器。如果不加role="menu"，屏幕阅读器只会把它当成一个普通的区块，用户根本无法感知这是个菜单。 - 你用
元素模拟了一个开关按钮。这时候必须加上role="switch"，并配合aria-checked来同步状态，否则依赖辅助技术的用户压根不知道这是个可以切换的控件。 - 你实现了一个自定义的弹窗遮罩层。正确的做法是添加
role="dialog"，同时务必处理好焦点的捕获，并设置aria-modal="true"。 - 页面顶部的导航区域，如果受限于老旧框架只能用
包裹，那改用role="na vigation"作为补充。
哪些 role 值容易误用
实际项目中，最常见的错误往往不是把role值写错，而是“画蛇添足”或造成了“语义冲突”。看看这几个反面教材：
- 在
元素上再加一个role="button"。原生本身就自带完整的语义和键盘交互行为，额外添加role反而可能干扰辅助技术对其默认行为的识别。 - 在
链接上添加role="link"。这同样是冗余操作。更糟的是，如果href值为空或仅仅是#，还会误导用户以为可以跳转。 - 在
标签上使用role="article"。这不仅仅是多余，在某些情况下还可能覆盖掉原生的隐含属性。 - 使用
role="none"或role="presentation"来隐藏某个元素的语义结构。这样做之前必须万分确认：它的子元素自身已经具备了足够的语义。否则，整块内容可能会被屏幕阅读器完全跳过，导致信息缺失。
role 和 aria-label 不是配套开关
这里需要厘清一个关键概念：role定义的是“它是什么”，而aria-label定义的是“它叫什么”。两者可以协同工作，但绝不能互相替代：
- 一个只有图标的按钮：
。它缺少可见文字，因此需要aria-label="删除项目"来告知名称，但它完全不需要role="button"，因为原生标签已经表明了身份。 - 一个带标题的卡片区域：
设置
...role="region"是合理的（因为没有更贴切的原生标签），而名称是通过aria-labelledby关联标题元素提供的，并非使用aria-label。 - 设置了
role="alert"却没有动态更新aria-live="polite"。这种情况屏幕阅读器可能完全不会播报内容变化，因为role本身并不会触发实时通知机制。
role 值的兼容性与运行时限制
并非所有role值在所有浏览器和屏幕阅读器的组合中都有完全一致的表现，尤其是在涉及复杂交互状态时，需要格外留意：
role="combobox"（组合框）要求同时管理aria-expanded、aria-controls、aria-activedescendant等多个关联属性。漏掉其中任何一个关键状态，都可能导致屏幕阅读器卡住或报出“未知控件”的错误。role="tree"（树形控件）和role="grid"（网格）对键盘导航逻辑有非常严格的要求。如果只加了个role标签，却没有用Ja vaScript实现对应的方向键、Home/End等导航行为，那无异于挂羊头卖狗肉。- 一些陈旧的辅助技术组合，例如旧版NVDA配合IE11，可能无法识别
role="feed"或role="doc-introduction"这类较新的文档角色。遇到这类情况，优先考虑降级方案，比如使用role="region"配合aria-label来替代。 - 所有
role值必须小写且拼写准确。role="Button"（首字母大写）或role="menubar"（少了个字母u）都会被浏览器直接忽略。
还有一个极易被忽略的要点：role属性一旦设置，就相当于锁定了该元素的语义身份。后续想通过Ja vaScript动态切换role值，比如从"tablist"改成"list"，屏幕阅读器几乎不会重新解析。与其在运行时费力折腾，更好的做法是使用不同的DOM结构，或者通过CSS来控制显示与隐藏。
