如何基于Chrome无障碍树实现桌面应用查询简单CSS选择器？

Chrome无障碍树包含足够信息，可重构出一个可能不完整但可用的虚拟DOM树。例如，在chrome://accessibility中查看测试页面时，会得到如下两条日志记录：

++++++ROLE_SYSTEM_PROGRESSBAR name='Your score is:' parent='ROLE_SYSTEM_GROUPING' window_class='Chrome_RenderWidgetHostHWND' value='91' OFFSCREEN FOCUSABLE display:inline-block tag:meter explicit-name:true valuetext:91 id:meter text-align:left currentValue=91 minimumValue=0 maximumValue=100 default_action='hacer clic en la superclase' action_name='clickAncestor' location=(521, 2570) size=(108, 22) index_in_parent=4 n_relations=1 n_characters=0 n_selections=0
++++++ROLE_SYSTEM_STATICTEXT name='new' parent='ROLE_SYSTEM_GROUPING' window_class='Chrome_RenderWidgetHostHWND' OFFSCREEN display:inline-block offset:0 background-color:rgb(153,153,0) color:rgb(200,195,188) font-family:Arial font-size:9pt language:es writing-mode:lr ia2_hypertext='new' default_action='hacer clic en la superclase' action_name='clickAncestor' location=(640, 2568) size=(41, 25) index_in_parent=5 n_relations=0 n_characters=3 n_selections=0

其中包含样式信息、元素标签名、元素ID等关键内容。

开发的桌面应用需要访问Chrome网页的DOM树，以运行基础CSS选择器并读取选中元素的值，当前聚焦Windows平台。

Chrome Accessibility APIs是官方方案，但未找到在该树上运行CSS选择器的示例。对于tagname、#id、[style^=""]、tagname > tagname这类简单选择器，实现查询会非常实用。目前计划解析整个无障碍树，用JSDOM重构DOM后运行CSS选择器，但该过程繁琐且可能存在未知边界情况。

是否有更清晰、直接的方法实现上述需求？

1. 利用Chrome DevTools Protocol（CDP）直接操作DOM #

这是最直接的方案，无需依赖无障碍树：

• 通过CDP的DOM域API，可直接获取页面完整DOM结构，支持调用DOM.querySelector或DOM.querySelectorAll执行CSS选择器查询，还能读取元素属性、文本内容或样式。
• Windows平台下，启动Chrome时添加--remote-debugging-port=9222参数，桌面应用通过WebSocket连接到调试端口，发送CDP命令即可实现交互。
• 优势：完全复用Chrome原生CSS选择器解析能力，避免重构DOM的繁琐和边界问题，能获取完整DOM信息，不限于无障碍树的子集。

2. 基于无障碍树实现轻量选择器引擎 #

如果必须依赖无障碍树，无需用JSDOM重构完整DOM，可针对目标选择器类型实现极简匹配逻辑：

• 预解析无障碍树节点数据，构建包含tag、id、style、父节点关系的树形结构。
• 针对不同选择器类型分别处理：
  • tagname：遍历所有节点匹配标签名；
  • #id：通过节点id属性快速查找；
  • [style^="xxx"]：检查节点style属性前缀匹配；
  • tagname > tagname：遍历父节点为指定标签的子节点。
• 优势：比重构DOM更轻量，仅处理需要的选择器类型，减少不必要开销。

3. 使用Chrome扩展作为中间层 #

开发简单Chrome扩展，在页面上下文执行CSS选择器查询，再通过Native Messaging传递结果给桌面应用：

• 扩展内容脚本直接调用document.querySelector等原生API，获取目标元素信息后发送给后台脚本；
• 后台脚本通过Native Messaging与桌面应用通信，传递数据。
• 优势：实现简单，无需处理CDP底层细节，扩展权限可控，适配Windows平台桌面应用集成。

内容的提问来源于stack exchange，提问作者Gaurang Tandon