document dom node should not have the "select node in inspector" icon in the side panel
Categories
(DevTools :: Accessibility Tools, defect)
Tracking
(Not tracked)
People
(Reporter: nchevobbe, Unassigned)
Details
Steps to reproduce
- Open the accessibility panel on this page
- Select the
document
item in the main panel - 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.
Comment 1•4 years ago
|
||
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.
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
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?
Comment 3•4 years ago
|
||
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?
Updated•4 years ago
|
Description
•