该用 aria-activedescendant 时是选项容器不可聚焦、选项为纯展示节点或需保持输入框键盘焦点；它让屏幕阅读器逻辑聚焦子元素而 DOM 焦点留在 input 上，须严格满足 role、id、aria 属性配对及可访问性要求。
aria-activedescendant 什么时候该用，而不是直接 focus() 选项元素
当组合框（如自定义 <select> 下拉）的选项容器不可聚焦、或选项本身是纯展示节点（比如 <div role="option"> 没有 tabindex），又或者你需要保持输入框始终获得键盘焦点（比如边输边搜场景），aria-activedescendant 就是唯一合规方案。它让屏幕阅读器把焦点“逻辑上”转移到某个子元素，而 DOM 焦点仍留在父容器（通常是 <input role="combobox">）上。
必须满足的 DOM 结构和属性配对
不配对就失效 —— 屏幕阅读器根本不会响应。关键三点：
-
<input role="combobox" aria-expanded="true" aria-activedescendant="id-of-option-2">：父输入框必须设role="combobox"，且aria-activedescendant值必须是当前活跃选项的id字符串（不能是 class 或 query selector） -
<div id="id-of-option-2" role="option" aria-selected="false">Apple</div>：每个选项必须有唯一id，且role="option"；若支持多选，还需加aria-selected - 选项必须是父容器的**可访问子节点**：不能用
display: none或visibility: hidden隐藏，得用aria-hidden="true"+hidden或仅视觉隐藏（如clip-path）
键盘导航时如何同步更新 aria-activedescendant
方向键（↑/↓）、Home/End 触发选项切换时，不能只改样式，必须手动更新属性：
inputEl.setAttribute('aria-activedescendant', 'option-3');
常见错误：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 忘记在首次展开下拉时设置初始值（比如默认高亮第一个选项）
- 滚动后选项移出视口，但
aria-activedescendant还指向原 ID，导致屏幕阅读器朗读错位 - 用
querySelector找选项却没处理null，脚本报错中断后续逻辑 - 未监听
input的keydown，而是监听了选项容器 —— 错误，焦点在 input 上，事件必须从 input 捕获
与 aria-selected、focus 样式的协同关系
aria-activedescendant 只管“谁被朗读”，不管“谁被高亮”。视觉焦点指示必须靠 CSS 和 JS 双重保障：
- 用
[aria-activedescendant="option-5"] + .options [id="option-5"]这类兄弟选择器做 CSS 高亮（需确保结构稳定） - 更可靠的做法：JS 在更新
aria-activedescendant后，显式给对应选项加class="focused"，再用 CSS 控制 -
aria-selected="true"是选中态，和活跃态无关；用户按Enter或Space后才应设它，此时也要同步清空其他选项的aria-selected - 别忘了
role="combobox"输入框要支持aria-autocomplete="list"（带建议列表）或"both"（带建议+可编辑），否则部分 AT 不触发列表朗读
最易忽略的是：当用户用鼠标点击选项，或失焦离开组合框时，aria-activedescendant 必须清空或重置，否则下次键盘操作会从错误位置开始。
