下拉菜单aria-expanded属性无障碍检测报错的原因及修复方案咨询

嘿，我之前也碰到过类似无障碍扫描工具“挑刺”的情况，咱们一步步来拆解你的问题哈～

首先得明确：你当前的aria-expanded状态切换逻辑（关闭时false、打开时true、选择选项后切回false）是完全符合WAI-ARIA规范的，而且combobox角色搭配aria-expanded属性也是合法的——规范里明确允许用它来指示下拉列表的展开/折叠状态，所以这部分你的思路没毛病。

那为什么AccessibleWeb会报错呢？大概率是这几个原因：

1. 工具规则的解读偏差或过时
   有些旧版的扫描工具规则可能还停留在“只有button元素才能用aria-expanded”的认知里，但WAI-ARIA 1.1及以后的规范已经放开了，combobox、menubutton等角色都可以搭配这个属性。AccessibleWeb偶尔会有这类规则的误触发。

2. 关联属性的小问题导致工具误判
   你的代码里aria-activedescendant在关闭状态下是空的，这本身没问题，但有些工具可能会因为这个“不完整”的属性，连带报错其他关联属性；另外也可以检查下aria-controls指向的listbox元素是否确实存在，且带有role="listbox"，里面的选项是否都加了role="option"——如果这些关联元素有缺失，工具可能会误判aria-expanded的合法性。

3. 工具本身的bug
   无障碍扫描工具不是100%准确的，尤其是针对动态交互组件的时候，有时候会出现无理由的误报。

接下来给你几个排查和修复的方向：

• 先确认规范正确性，不用慌
  你当前的状态切换逻辑是无障碍最佳实践，这一点是站得住脚的，别因为工具报错就否定自己的实现。

• 检查关联属性的完整性

  • 确保aria-controls对应的listbox元素存在，且正确设置了role="listbox"，每个选项都有role="option"
  • 当combobox打开时，aria-activedescendant要能正确指向当前聚焦的option；关闭时设为空是合理的，不用改
  • 确认tabindex="0"设置正确，保证这个combobox能被键盘正常聚焦

• 针对工具报错的应对小技巧

  • 标记误报：如果确认自己的实现完全符合规范，直接把这个报错标记为误报就行，很多团队都会碰到这种情况
  • 调整属性顺序：虽然规范不要求属性顺序，但有些工具对顺序敏感，比如把aria-expanded移到aria-haspopup后面试试，说不定能绕过工具的规则检测
  • 替换成button元素：如果工具死咬着报错，不如把span换成button——button天然支持aria-expanded，而且自带回车/空格触发的键盘交互，不用你额外绑定事件，无障碍体验反而更好（只需要调整下button的默认样式就行），比如：

    <button role="combobox" id="id-bla-bla" aria-haspopup="listbox" aria-expanded="false" aria-controls="bla-bla" aria-label="Label Text" class="class-bla-bla" aria-activedescendant="">
      Chosen Value
    </button>
    

• 一定要做手动无障碍测试
  扫描工具只能检测静态属性，真正的无障碍体验要靠屏幕阅读器（比如NVDA、VoiceOver）来测试：打开combobox时，屏幕阅读器应该能读出“展开”，关闭时读出“折叠”，选择选项后能正确朗读选中的值——如果这些都没问题，那就算工具报错，你的实现也是合格的。

内容来源于stack exchange