element.matches()无法校验ARIA规范合规性，仅能按CSS选择器匹配元素；可用于快速筛选带特定ARIA属性的元素作为无障碍检测前置步骤，但不验证语义、值合法性或隐式角色。
直接用 element.matches() 无法校验 ARIA 规范是否合规——它只判断 CSS 选择器匹配，不验证 ARIA 属性语义、角色约束或 WCAG 合规性。但你可以用它快速筛选出“带特定 ARIA 属性的元素”，作为无障碍检测流程中的前置过滤步骤。
用 matches() 快速定位需检测的 ARIA 元素
在扫描页面无障碍问题前，先缩小目标范围。例如只检查所有带 role="button" 或含 aria-expanded 的交互元素：
-
element.matches('[role="button"]')—— 找出显式声明按钮角色的元素（包括非<button>标签） -
element.matches('[aria-expanded],[aria-pressed],[aria-selected]')—— 一次捕获多种状态属性，避免多次hasAttribute判断 -
element.matches('input[type="checkbox"][aria-checked]')—— 检查冗余或冲突定义（原生type="checkbox"不该再设aria-checked）
配合 ARIA 规则做轻量级逻辑校验
matches() 本身不校验规则，但可组合属性读取，实现简单逻辑断言。例如验证“折叠面板触发器必须同时有 aria-expanded 和 aria-controls”：
if (el.matches('[aria-expanded]') && !el.hasAttribute('aria-controls')) { console.warn('缺少 aria-controls'); }if (el.matches('[role="tab"][aria-selected="true"]') && !el.closest('[role="tablist"]')) { console.warn('tab 缺少 tablist 父容器'); }
这类检查不能替代完整 a11y 扫描，但适合在开发中快速拦截明显错误。
注意 matches() 在 ARIA 场景下的典型误用
它容易被当成“无障碍检查工具”，但实际能力有限，需避开这些坑：
- 不支持运行时状态：如
el.matches(':focus')永远返回false；想查焦点状态，应改用document.activeElement === el - 不校验值合法性：
el.matches('[aria-live="politee"]')会返回true（语法合法），但"politee"是无效值，需额外判断el.getAttribute('aria-live')是否为"off"、"polite"或"assertive" - 不识别隐式语义：
el.matches('nav')成立，但若没加role="navigation"，屏幕阅读器可能不识别其导航用途——matches() 无法提醒你补 ARIA 角色
真正校验 ARIA 规范，得靠专用工具
matches() 只是“找人”，不是“审人”。完整 ARIA 合规性检测需结合：
-
axe-core：自动扫描
aria-*属性缺失、冲突、无效值、角色-属性不匹配等 50+ 条规则 -
@testing-library/aria：提供
getByRole()等查询方法，强制按 ARIA 语义查找，倒逼正确标注 - 手动检查表：如 WAI-ARIA Authoring Practices 中的组件模式（如 Dialog、Treeview），需逐项核对角色、属性、键盘行为、焦点管理
matches() 最合适的位置，是写在这些工具之前的轻量过滤层，或嵌入到自定义 hook 中做实时提示，而不是独立承担校验职责。
