*ByLabelText() with aria-hidden elements

[JeremyGrieshop]

Versions

• @testing-library/jest-dom version: 5.8.0
• @jest-environment-jsdom-sixteen: version 1.0.3

Relevant code or config:

const component = () => 
    <div>
        <label id="MyLabel" for="MyInput">My Label<span aria-hidden="true">*</span></label>
        <input id="MyInput" value="some value" />
    </div>

What you did:

I was testing a material-ui component, using the "required" property, which adds an asterisk to the label automatically.

What happened:

The *ByLabelText() methods do not find the label, because the asterisk is included. However, I thought with the aria-hidden attribute in there, it would exclude that part, just as screen readers do to locate and announce labels.

Reproduction:

Here's a forked codesandbox example:

https://codesandbox.io/s/react-testing-library-demo-pxex9?file=/src/__tests__/hello.js

Problem description:

I'm not sure if this is expected, but I thought getByLabelText("My Label") would return a valid input. Instead, I have to use getByLabelText("My Label*"), because it finds the asterisk in there.

Suggested solution:

Honor aria-hidden elements by skipping them when locating labels, to be consistent with screen readers.

[eps1lon]

Honor aria-hidden elements by skipping them when locating labels, to be consistent with screen readers.

There's much more that would go into it. For complex labels we recommend ByRole('textbox', { name: 'My Label' }) which should consider all these intricacies. ByLabelText is for simple labels.

[JeremyGrieshop]

Honor aria-hidden elements by skipping them when locating labels, to be consistent with screen readers.

There's much more that would go into it. For complex labels we recommend ByRole('textbox', { name: 'My Label' }) which should consider all these intricacies. ByLabelText is for simple labels.

Thanks for taking the time to comment on this. I understand that it's likely a complex problem. I may take your advice, or I can certainly add more metadata to my DOM elements to achieve a test that succeeds. I was just hoping that my tests could serve to pass and assure that they are reasonably accessible at the same time.

[eps1lon]

or I can certainly add more metadata to my DOM elements to achieve a test that succeeds.

Could you explain why ByRole does not work for you?

[smeijer]

cc: @delca85. Didn't you have similar experiences with aria-hidden?

[JeremyGrieshop]

or I can certainly add more metadata to my DOM elements to achieve a test that succeeds.

Could you explain why ByRole does not work for you?

My use-case is a pretty abstract and the codesandboxio was an extremely simplified example to demo the problem. In my case, I'm testing generic components for whose implementation I don't always know about and I may not be able to understand its "role", or its structure, unless I make that a meta-component requirement. But, knowing that all components have accessible labels is one thing I try to check for and so I thought getByLabelText() would be a good method to achieve this.

[delca85]

cc: @delca85. Didn't you have similar experiences with aria-hidden?

react-testing-library worked as expected for me with the attribute aria-hidden set to true, it doesn't find any role for the selected element.

[eps1lon]

But, knowing that all components have accessible labels is one thing I try to check for and so I thought getByLabelText() would be a good method to achieve this.

The issue is that the "label" i.e. accessible name depends on the role. Not all roles compute the same label so you're already implicitly coupling your test to the role. Again, especially if your component is more complex, do use ByRole instead. It is much more robust than ByLabelText can ever be. Otherwise we'd just remove one of them.

But, knowing that all components have accessible labels is one thing I try to check for and so I thought getByLabelText() would be a good method to achieve this.

This sounds like you want to make an assertion about a given element not query an element. For that task you can use dom-accessibility-api directly. I think we want to have a jest matcher for that anyway at some point. We're using a custom toHaveAccessibleName matcher in Material-UI which sounds just like what you're trying to do. Example implementation:

import { computeAccessibleName } from 'dom-accessibility-api';
function toHaveAccessibleName(element, expected) {
  console.assert(computeAccessibleName(element) === expected);
}

Full implementation using chai

dom-accessibility-api is used internally by @testing-library/dom.

[JeremyGrieshop]

The issue is that the "label" i.e. accessible name depends on the role. Not all roles compute the same label so you're already implicitly coupling your test to the role. Again, especially if your component is more complex, do use ByRole instead. It is much more robust than ByLabelText can ever be. Otherwise we'd just remove one of them.

Clearly, I have a lot of learning to do in the realm of a11y. You're hitting on some concepts that I hadn't realized about role/label relationships. I will start there and revisit/reopen if need be.

This sounds like you want to make an assertion about a given element not query an element. For that task you can use dom-accessibility-api directly. I think we want to have a jest matcher for that anyway at some point. We're using a custom toHaveAccessibleName matcher in Material-UI which sounds just like what you're trying to do. Example implementation:

import { computeAccessibleName } from 'dom-accessibility-api';
function toHaveAccessibleName(element, expected) {
  console.assert(computeAccessibleName(element) === expected);
}

Full implementation using chai

dom-accessibility-api is used internally by @testing-library/dom.

Very interesting, thank you, I'll read through the docs for dom-accessibility-api.

[kentcdodds]

It looks like there's nothing actionable from here so let's close this 👍

[JeremyGrieshop]

or I can certainly add more metadata to my DOM elements to achieve a test that succeeds.

Could you explain why ByRole does not work for you?

I realized that this didn't work at first because I left off type="text" to my input and so the "textbox" role didn't return anything. This absolutely works and it's what I'm going to use for testing in lieu of ByLabel() calls. Thanks!