aria-multiselectable 的核心作用是声明容器支持多选，需配合 role 和 aria-selected 使用。具体步骤：1. 在容器上设置 role="listbox/grid/tree" 及 aria-multiselectable="true"；2. 子元素设为 role="option" 等对应角色；3. 通过 aria-selected 标记选中状态；4. javascript 实现多选逻辑及视觉反馈；5. 配合键盘交互与焦点管理确保无障碍性。
aria-multiselectable 这个 ARIA 属性，它的核心作用是向辅助技术（比如屏幕阅读器）表明，一个容器内的子元素是支持多选的。简单来说，它告诉屏幕阅读器用户可以在这个组件里一次性选择多个项目，而不是只能选一个。这对于构建可访问的复杂交互组件，比如多选列表框、表格或树形结构，至关重要。
解决方案
要正确使用 aria-multiselectable，你需要把它应用到承载可选择子元素的容器上。这个容器必须先声明一个合适的 ARIA role，比如 listbox（列表框）、grid（网格）或 tree（树）。这些 role 本身就包含了可选择项的概念。
举个例子，如果你在构建一个可以多选的列表框：
立即学习“前端免费学习笔记（深入）”；
-
容器元素：给
<ul>或<div>这样的容器元素设置role="listbox"和aria-multiselectable="true"。 -
子元素：容器内的每个可选项（比如
<li>）需要设置role="option"。 -
选择状态：当一个子元素被选中时，你还需要给它添加
aria-selected="true"。如果未选中，可以设置aria-selected="false"或者干脆不设置这个属性（默认就是未选中）。
这里有一个简单的 HTML 结构示例：
<div id="my-multiselect-list" role="listbox" aria-multiselectable="true" tabindex="0"> <div role="option" id="option1" aria-selected="false">选项一</div> <div role="option" id="option2" aria-selected="true">选项二 (已选中)</div> <div role="option" id="option3" aria-selected="false">选项三</div> <div role="option" id="option4" aria-selected="true">选项四 (已选中)</div> </div>
关键点在于： aria-multiselectable 仅仅是声明了容器的“多选能力”，它本身并不实现多选的逻辑。实际的多选行为（比如用户按住 Ctrl/Cmd 键点击、按住 Shift 键选择范围等）需要通过 JavaScript 来实现。JavaScript 会根据用户的操作动态地更新子元素的 aria-selected 属性，并提供相应的视觉反馈。
为什么 aria-multiselectable 常常被误解或错误使用？
这确实是个常见的问题，我在实际项目中也遇到过不少。我觉得主要原因在于对 ARIA 属性的理解不够深入，尤其是混淆了“声明能力”和“表示状态”的区别。
一个典型的误区就是把 aria-multiselectable 当成是 aria-selected 的替代品，或者以为只要加上它，多选功能就自动具备了。但实际上，aria-multiselectable 是给父容器用的，它告诉辅助技术“我这个组件里的东西可以多选”，而 aria-selected 才是真正标记单个项目是否被选中的状态。它们是协同工作的，缺一不可。
另一个常见错误是忘记给容器设置正确的 role。aria-multiselectable 并不是万能的，它只对特定的复合组件角色（如 listbox, grid, tree）有意义。如果你把它用在一个普通的 div 上，而没有相应的 role，那么它的语义信息就无法被辅助技术正确解析。
此外，很多开发者在实现多选时，往往只关注了鼠标交互，而忽略了键盘交互。对于多选组件，键盘操作（如使用方向键导航，配合 Ctrl/Cmd 或 Shift 键进行选择）是无障碍访问的基石。如果只有 aria-multiselectable 属性而没有对应的键盘事件处理逻辑，那么这个组件对键盘用户来说几乎是不可用的，这会大大损害用户体验。
与 aria-multiselectable 搭配使用的核心 ARIA 角色和状态有哪些？
要构建一个真正可访问的多选组件，光有 aria-multiselectable 远远不够。它需要一系列 ARIA 属性和角色来共同构建完整的语义信息。
首先，角色（Roles） 是基础：
-
role="listbox": 最常见的多选场景，用于列表形式的选择器。它的子项通常是role="option"。 -
role="grid": 用于表格或网格布局的多选，比如数据表格中选择多行。它的子项是role="row"，而row的子项是role="gridcell"。 -
role="tree": 用于树形结构的多选，比如文件浏览器。它的子项是role="treeitem"。
其次，状态（States） 提供了动态信息：
-
aria-selected="true/false": 这是与aria-multiselectable配合最紧密的属性。它直接告诉辅助技术某个特定的子项是否被选中。当用户选择或取消选择一个项目时，这个属性的值必须通过 JavaScript 动态更新。 -
aria-activedescendant: 对于那些不直接管理焦点（tabindex="-1"）但需要指示当前活动元素的复合组件（如listbox、grid），aria-activedescendant就显得尤为重要。它设置在容器元素上，指向当前通过键盘导航激活的子元素的 ID。这使得屏幕阅读器能够跟随用户的键盘焦点，即使实际的 DOM 焦点可能还在容器上。 -
tabindex="0": 容器元素通常需要设置tabindex="0"，使其可以通过 Tab 键获得焦点。一旦容器获得焦点，内部的导航（如方向键）和选择（如 Space 键、Enter 键）就由 JavaScript 和aria-activedescendant来管理。 -
aria-labelledby和aria-describedby: 这些属性用于为整个多选组件提供可访问的名称或描述。例如，你可以用aria-labelledby指向一个label元素的 ID，来清晰地说明这个多选组件的用途。
这些属性共同协作，为辅助技术描绘出一个完整、准确的多选组件模型，确保用户能够理解其功能并进行有效交互。
实现多选无障碍性时的实际考量和常见挑战
在实际开发中，仅仅设置 ARIA 属性是远远不够的。真正的挑战在于如何将这些语义与实际的用户交互（特别是键盘交互）无缝结合起来。
一个非常重要的考量是键盘导航和操作。多选组件的键盘交互模式通常比较复杂：
-
方向键（Up/Down/Left/Right）：用于在选项间移动焦点（通常是更新
aria-activedescendant）。 - 空格键（Space）：用于切换当前聚焦选项的选中状态。
- Ctrl/Cmd + 点击/空格：用于在不取消其他选项选择的情况下，切换单个选项的选中状态。
- Shift + 点击/方向键：用于选择一个范围内的多个选项。
- Home/End 键：快速跳转到列表的开始或结束。
这些复杂的键盘逻辑都需要通过 JavaScript 精心实现。如果缺少这些交互，即使 aria-multiselectable 设置正确，组件的可用性也会大打折扣。
另一个挑战是视觉反馈。当用户选中或取消选中一个项目时，除了更新 aria-selected 属性外，还必须提供清晰的视觉指示。这可以通过改变背景色、添加边框、显示复选框图标等方式实现。视觉反馈对于所有用户都很重要，它帮助用户理解当前的状态，尤其是在多选场景下，用户需要明确知道哪些项目已被选中。
焦点管理也是一个容易出错的地方。当组件获得焦点时，如何确保屏幕阅读器能正确报读当前活动项？当用户完成选择后，焦点应该回到哪里？这些都需要仔细规划。使用 aria-activedescendant 是一个好方法，但它也意味着你需要手动管理 DOM 焦点和视觉上的“活动”状态。
最后，测试是不可或缺的一步。仅仅在浏览器中查看效果是不够的。你必须使用主流的屏幕阅读器（如 Windows 上的 NVDA/JAWS，macOS 上的 VoiceOver）进行实际测试，模拟视障用户的使用场景。你会发现很多看似完美的代码，在屏幕阅读器下可能表现得一塌糊涂。通过测试，你才能发现那些隐藏的无障碍性问题，并进行迭代改进。这不仅仅是技术实现，更是一种用户同理心的体现。
