如何修复role="tablist"/role="tab"引发的Axe无障碍检测违规问题

修复必要性说明 #

这两项Axe违规属于影响核心无障碍可用性的必修复问题，优先级很高：

• 不符合WCAG 2.1 A级标准要求，如果你的产品需要满足公共服务无障碍合规要求（比如国内《信息无障碍通用规范》、海外Section 508条款），属于强制修复项。
• 实际会导致视障用户的使用障碍：屏幕阅读器无法正确识别标签页的层级结构，标准的标签页键盘交互（左右方向键切换标签）大概率会失效，视障用户根本无法正常使用这个组件。

第二项违规的触发逻辑 #

你对ARIA规范的理解没有错，ARIA本身没有强制role="tab"必须是role="tablist"的直接子元素。但Axe的这个规则是基于ARIA的隐式语义链校验：当你给<ul>加了role="tablist"之后，它的原生列表语义被覆盖，直接子元素<li>没有对应的ARIA角色承接，打断了tablist到tab的语义关联，辅助技术无法从tablist下定位到tab元素，因此触发违规。

最优解决方案（改造成本极低） #

完全不需要迁移交互逻辑到<li>上，只需要给所有<li>元素加上role="none"（或role="presentation"）即可，这两个角色的作用是告知辅助技术忽略该元素的原生语义，既不影响你原有的CSS、JS逻辑，又能同时解决两项违规：

<ul role="tablist">
  <li role="none">
    <div role="tab" tabindex="0" aria-selected="true" aria-controls="id1">First tab content...</div>
  </li>
  <li role="none">
    <div role="tab" tabindex="-1" aria-selected="false" aria-controls="id2">Second tab content...</div>
  </li>
</ul>

额外补充说明 #

• 你原来的第二项标签没有加tabindex="-1"、aria-selected="false"和aria-controls属性，建议顺便补上，符合标签页的标准交互规范，不会增加额外改造成本。
• 这个方案完全避开了你之前把role="tab"移到<li>上导致的嵌套交互问题，原有绑定在内部<div>上的点击、键盘事件都不需要做任何调整。

内容的提问来源于stack exchange，提问作者Paul Pearson