getByRole should not find the element with user custom and invalid ARIA role.

[mrdulin]

• @testing-library/dom version: -
• Testing Framework and version: -
• DOM Environment: https://testing-playground.com/

Relevant code or config:

<div role='item'>
  apple
</div>

// query
screen.getByRole('item')

What happened:

The testing playground query the element successfully and told me the div element has an "item" role.

Problem description:

But the "item" role is not a pre-defined ARIA role, so I expect that screen.getByRole('item') should not find the element.

[eps1lon]

This would block testing new roles (or experimental roles).

So if we start blocking (or warning about) unknown roles, we also need to add a configuration open to add available roles. People might not be able to upgrade Testing Library but are able to use new roles.

[beanscg]

Bean Labs took a public-source pass on this issue.

The narrowest useful next step looks like: Offer a public comment that narrows the keyboard/ARIA or screen-reader expectation and identifies the component, example, or docs page to verify.

Public evidence checked:

• GitHub direct issue read: open, unassigned, comments=1, labels=none.
• Repository metadata read: license=MIT; archived=false.
• Body references files/examples: CODE_OF_CONDUCT.md, package.json

A good acceptance check would be a narrow public change that directly exercises the issue's reported boundary.

No PR opened from this pass.