Steps to reproduce

1. Open the accessibility panel on this page
2. Select the document item in the main panel
3. Spot the DOMNode item in the side panel

Expected results

There shouldn't be the crosshair icon that opens the inspector

Actual results

The icon is visible, hovering it doesn't highlight the page, and clicking it open the inspector, but the body node gets selected.

Maybe there shouldn't even be a DOMNode item? After all it doesn't match a real dom node.

Hey :nchevobbe. Why do you feel it shouldn't open the DOM Inspector to the body node? The document accessible does pretty much correspond to the body DOM node and the children of the body DOM node will be children of the document accessible. For example, ARIA role="application" on the body DOM node gets mapped to the document accessible. There is some stuff that is taken from the root element and/or title element, but for the most part, they correspond.

I'm wondering, then, whether this bug is more about the highlighting than the ability to inspect it.

I don't feel super strong about it. What I found confusing was having a DOMNode property value being document (because document isn't a DOM Node).
Then having the icon was more for consistency with the rest of DevTools: if I evaluate document in the console, in the result we don't have the icon to link to the inspector (same in the Debugger or in the DOM panel).

Yura, what's your opinion on this?

One important thing to note: when we have iframes Inspector tree does expose #document which maps nicely to AccessibleDocument in the accessibility tree so this issue is really only scoped to the top level document.

I think there are 2 things here: top level AccessibleDocument's corresponding DOMNode is document. When inspecting in Inspector, body will not have a highlight so switching for that purpose is not adding much value (and is not much of a use case).

One use case would be something like:

• user notices that the document has an accessibility issue because it does not have a name
• user navigates to Inspector panel and lands on the body. That won't really help the user with the name issue, because they would likely need to add a title inside a head to properly fix it.

Another one is indeed something that Jamie mentions which is the user wants to see what children the body element has and how they correspond to children pf AccessibleDocument.

I guess what I'm trying to say here is that, in context of accessibility tools, quick navigation between panels like this is helpful and helps users to stay within the scope of their task. Perhaps alternative could be selecting something other than the body for top level AccessibleDocument?