绝大多数情况下无需手动写role属性；原生语义明确的元素（如<button>、<nav>、<main>）显式加role会覆盖默认角色，导致读取错误或交互异常；仅在用<div>、<span>模拟复杂控件且无法用原生元素替代时才需补role，并须同步处理焦点与键盘操作。
绝大多数情况下不需要手动写 role 属性——浏览器和辅助技术已经能从 HTML 元素语义中自动推导出正确的 ARIA 角色。
哪些元素写 role 会覆盖原生语义？
给原生语义明确的元素（如 <button>、<nav>、<main>）显式加 role，可能覆盖其默认角色，导致屏幕阅读器读错或功能异常。
-
<button role="link">→ 屏幕阅读器会把它当链接读，但键盘焦点仍按按钮行为处理（Enter 可触发，Space 不触发），交互逻辑断裂 -
<nav role="banner">→ 原本的navigation角色丢失，可能让视障用户跳过整个导航区 - 例外：仅当需要修正严重渲染缺陷（如某些旧版 Safari 对
<dialog>支持不全）时，才考虑临时加role="dialog"并配齐aria-modal等属性
什么时候必须写 role？
只有在使用无语义容器（<div>、<span>）模拟复杂控件，且无法用原生元素替代时，才需补 role。
- 用
<div>实现下拉菜单：必须加role="combobox"或role="listbox"，并配合aria-expanded、aria-controls等 - 自定义滑块：用
<div>+ 拖拽实现，需role="slider"、aria-valuenow、aria-valuemin、aria-valuemax - 注意：此时还要手动处理键盘焦点（
Tabindex）、键盘操作（ArrowKeys/Enter/Space）和焦点管理，否则只是“挂羊头卖狗肉”
role="presentation" 和 role="none" 怎么选？
两者都用于移除元素的角色暴露，但兼容性不同：
-
role="none"是 ARIA 1.1+ 推荐写法，语义等同于role="presentation" -
role="presentation"在 IE11 和旧版 JAWS 中支持更稳，若需兼容这些环境，优先用它 - 别滥用：比如给图标
<i class="icon-home"></i>加role="presentation"是合理的；但给包含文本的<div>用户名</div>加，会导致内容被完全忽略
真正难的不是写不写 role，而是判断「这个 UI 是否本该用原生元素实现」——多数可访问性问题，根源在于用 <div> 硬套功能，而不是补几个 ARIA 属性就能修好的。
