[Bug]: `toMatchAriaSnapshot` does not respect `ElementInternals`

[mrginglymus]

Version

1.49.1

Steps to reproduce

https://github.com/mrginglymus/pw-asei

This repo contains a custom element that sets role to heading on its ElementInternals instance.

Inspecting this element in chromiums accessibility tree shows that it has seen it as a heading:

Expected behavior

Test in repo to pass

Actual behavior

Test in repo does not detect element as heading.

Additional context

No response

Environment

System:
    OS: Windows 10 10.0.19045
    CPU: (24) x64 Intel(R) Core(TM) i9-10920X CPU @ 3.50GHz
    Memory: 26.72 GB / 63.80 GB
  Binaries:
    Node: 22.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 4.6.0 - C:\Program Files\nodejs\yarn.CMD
    npm: 10.9.0 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Bash: 5.1.16 - C:\WINDOWS\system32\bash.EXE
  npmPackages:
    @playwright/experimental-ct-react: ^1.49.1 => 1.49.1

[pavelfeldman]

I don't think we support ElementInternals at all, not even in our selectors. Setting a P3 state to collect stars and check in 6 months.

[mrginglymus]

A related issue on axe: https://github.com/dequelabs/axe-core/issues/4259 - looks like the JS APIs just aren't there yet for this.

[robdodson]

I think I may have just run into this issue as well. I have a pretty simple Tabs custom element:

constructor() {
  super();
  this.#internals = this.attachInternals();
  this.#internals.role = "tab";
}

The role seems to be working in Chrome's inspector

But getByRole('tab') does not work, and the inspector in Playwright's version of Chromium does not show the role (it just says it's 'generic')

[ITenthusiasm]

I don't think we support ElementInternals at all, not even in our selectors. Setting a P3 state to collect stars and check in 6 months.

I will say: I expect this (the ability to properly derive information from ElementInternals) to be very valuable as time goes on. Right now, there are problems that only Web Components can solve -- and increasingly so as more features get established. For example, formAssociated Custom Elements provide the ability for devs to create their own form controls that are recognized by the browser. This is huge because it removes the need for complex state management tools which form libraries previously had to provide for, say, React components that are "non-native form controls". JS Frameworks cannot solve the form control problem.

This might not be valuable in the immediate future due to the fact that some features have only been Baselines since 2023/2024 according to MDN. But I'm confident it will be valuable in the "near enough" future. If this (or other ElementInternals issues) are closed, they will likely be newly-created by others later.

So this might be something to hold onto for a bit rather than close early if interest doesn't spike soon. I remember Kent C. Dodds asked for toHaveAccessibleDescription(). It wasn't "popular". It got closed. He said, it was something people "didn't know they needed yet". Later, that proved to be true. I feel this falls in that category -- or will in a year or two when these new WC features are more established.

---

In the meantime, setting the role attribute explicitly on WCs is probably the best workaround.