Extension display of shadow DOM selectors is confusing

[OSnuszka]

Product

axe-core

Question

I use this tool for accessibility scanning and noticed that it doesn’t accurately indicate selectors for shadow root, which makes me doubt whether they are being properly checked. Is there any configuration I should be aware of? I would really appreciate your help.

[WilcoFiers]

I'm not sure I understand what you mean. Shadow roots are not elements, you cannot select them, style them, or add attributes to them. What would you expect see axe do with them? Can you give an example?

[OSnuszka]

You’re right, I misspoke. I meant elements inside the shadow root. When I run an accessibility scan, axe doesn’t seem to provide precise selectors for elements within shadow DOM, which makes me unsure if they are actually being checked.

Is there a specific configuration I should use to ensure axe properly scans elements inside shadow roots? Here’s an example of what I’m seeing:

└── shadow-root (open)
    └── <button>Click me</button>

[WilcoFiers]

What selector are you getting? One difficulty is that there is no way to target elements with a CSS selector across shadow DOM boundaries (nor frame boundaries for that matter). The way axe-core does it is by creating multiple selectors.

<my-div>
  <template shadowrootmode="open">
    <button></button>
  </template>
</my-div>

This button-name issue for example results in an array of selectors: ['my-div', 'button'] In the axe extension this is concatinated with a comma between them so you may see "my-div,button" in the element location property. Is that what you're getting?

The other thing that could be going on is that we somewhat recently fixed an issue where the children inside shadow dom roots were not guaranteed to have a unique selector. That should be fixed in 4.10.1, are you using that?

If it's something else, could you provide some steps to reproduce the issue with?

[OSnuszka]

Yes I see It: parentSelector,.selectorInsideOpenShadowRoot

So, Axe-core saves selectors in the form of div,button to bypass the limitations of the DevTools' element inspector and the lack of an option to target the shadow root directly.

I see another discrepancy because I’m comparing results with the tool https://www.tpgi.com/arc-platform/arc-toolkit/ and generally, it found errors related to the description:

Description: The aria-label attribute is not allowed on the generic role
WCAG 2.2 Success Criterion:A 4.1.2 Name, Role, Value

<custom-button> component="custom-button" aria-label="accessibility_label_default_1" </custom-button>

(This error is valid)

But Axe-core doesn't catch this, so what could be the reason for the difference in the reports?

[OSnuszka]

Actually, I apologize – the error falls under the "Best Practices" category in Axe-core, and it does catch it. The ARC tool, on the other hand, shows it as an error under the WCAG 2.2 Success Criterion A 4.1.2 Name, Role, Value, which is a bit misleading.

[WilcoFiers]

I'll bring the UI question to the extension team. I think that's a valid point, a comma is confusing here as comma itself is a valid selector.

As for aria-label on generic, yes axe treats this as a best practice. It is true that aria-label on a generic element could get ignored by assistive technologies. That's only a problem if the information on aria-label is actually required. There are a lot of scenarios where we don't think it is, which is why axe is not failing it for WCAG.