aria-owns仅在DOM物理结构与逻辑语义必须分离时才必需使用，如Portal渲染的弹出层挂载在body下但需归属触发控件、拖拽后强制读屏器按视觉顺序朗读、或动态归并独立选项到列表中；若元素本已正确嵌套，则添加该属性反而破坏可访问性树。
aria-owns 不是用来“修复布局”或“绕过 CSS 定位限制”的，它只在 DOM 物理结构与逻辑语义必须不一致时才生效——比如弹出层挂载在 <body> 下，但语义上必须是某个按钮的子菜单。
什么时候必须用 aria-owns？
只有当视觉结构和可访问性树必须分离，且无法靠嵌套解决时，它才是刚需：
- React/Vue 中通过
Portal渲染的dropdown、tooltip、combobox弹层，DOM 上是<body>的子节点，但逻辑上必须归属触发控件 - 拖拽排序后需强制读屏器按视觉顺序朗读（例如把第 3 项移到第 1 位，但 DOM 位置未变）
- 动态重组控件层级，比如把独立的
<div role="option">临时归入另一个listbox下
如果元素本就嵌套在父容器内，加 aria-owns 反而会覆盖默认父子关系，导致读屏器跳过真实子节点。
aria-owns 值写错的常见表现
写了却没被读出来？大概率不是语法错误，而是链路断在了某处：
立即学习“前端免费学习笔记（深入）”；
- 目标元素没有
id，或id拼写不一致（aria-owns="menu-1"对应的却是id="menu1"） - 目标元素还没插入 DOM 就提前设置了
aria-owns（尤其在 JS 动态渲染场景） - 目标元素缺失
role，比如<div id="search-dropdown">没加role="listbox"，即使有 ID 也不会进可访问性树 - 源元素本身被
aria-hidden="true"或inert禁用，整个控制关系被忽略
别依赖 DevTools 的“Accessibility”面板判断是否生效——它只显示属性存在，不校验可访问性树是否真被重构。
源元素和目标元素的角色怎么配？
角色不匹配会导致语义冲突，读屏器可能静默跳过或报错：
- 源元素（拥有者）要有明确交互角色：如
role="combobox"、role="button"、role="tab"；纯<div>或没role的按钮不会触发aria-owns解析 - 目标元素（被拥有者）角色需与上下文一致：下拉菜单用
role="listbox"，提示框用role="tooltip"，模态框用role="dialog" - 禁止让
role="button"拥有另一个role="button"——父子角色不能逻辑冲突 - 目标元素不能是
aria-hidden="true"、display: none或visibility: hidden状态，否则辅助技术直接忽略
如果目标是动态插入的，务必等 document.getElementById() 能取到该节点后再设置 aria-owns，否则值无效且后续也不自动恢复。
最易被忽略的一点：一旦目标元素从 DOM 中移除，必须同步清空源元素上的 aria-owns 值。残留一个已销毁的 ID，会让整个属性解析失败，影响后续所有 ARIA 关系的识别。
