Button's inner text is ignored when label exists, even though aria-hidden is set to true

[alex1701c]

Heyho,
I have the problem that a button component has a label which has aria-hidden="true" causes findByRole to not look at the button's inner text.
In case I remove the for attribute from the label, it works as expected. But according to the accessibility tab in the browser, the label is ignored even with the for attribute set.

• @testing-library/dom version: ^8.20.0
• DOM Environment:
  @testing-library/cypress: ^9.0.0
  cypress: ^12.3.0

Relevant code or config:

[
    'button1', // The correct for attribute pointing to the button, this causes the last finyByRole to fail
    undefined, // Don't set this attribute
].forEach((labelFor) =>
    it('should find button', () => {
        cy.mount(
            <div className="SCFormControl">
                {/* The label is needed due to some internal layout, other controls always have a label containing the user-visible text */}
                <label id="button1_label" htmlFor={labelFor} aria-hidden="true"></label>
                <button type="button" id="button1">
                    <span className="somestylingclasses">Button 1</span>
                </button>
            </div>,
        );
        cy.findByText('Button 1').should('exist');
        cy.findByRole('button').should('exist');
        cy.findByRole('button', { name: 'Button 1' }).should('exist');
    }),
);

What happened:

Reproduction:

See attached code snippet

[lausuarez02]

I've been looking at the error and the only thing that i see that could generate an error is the fact that instead of using a string to get the name of it you should probably try using this syntax name: /Button 1/i .
Apart from that i don't see another error, check that out, i hope that helps. ;)

[alex1701c]

I've been looking at the error and the only thing that i see that could generate an error is the fact that instead of using a string to get the name of it you should probably try using this syntax name: /Button 1/i .

That does not help. Did you try it with the attached cypress snippet?

[timdeschryver]

It seems like this needs to be resolved in dom-accessibility-api, specifically within computeAccessibleName. However, I'm not sure if this is a bug, or the desired outcome. From my tests my screen reader (windows narrator) finds the button with name Button 1, but the accessibility tree of my browser also finds the button but with the content of the label which is invisible.

[alex1701c]

From my tests my screen reader (windows narrator) finds the button with name Button 1

Yep, same with NVDA.

but the accessibility tree of my browser also finds the button but with the content of the label which is invisible.

Hmm, that is a good point, but even a non-empty aria-hidden label will result in an empty text.

Consider the following example:

<div class="SCFormControl">
    <label id="button1_label" for="button1" aria-hidden="true">Screenreader ignores me :(</label>
    <button name="bla" type="button" id="button1">
        Button 1
    </button>
    <label>But not me!</label>
</div>

As you can see with the label texts, the button1_label is completely ignored, even with a non-empty text.
In the accessibility tab, the label is ignored, but I am not sure why the computed content is considered invalid.

[MatanBobi]

This is a tricky one. The accessible name computation algorithm doesn't state that one specifically if I understand correctly here:
https://www.w3.org/TR/accname-1.2/#terminology

What happens in dom-accessibility-api is that the label is linked to the button and since the label is hidden, the result of it is an empty string.

@eps1lon do you maybe have an idea about this specific use case? I'm not sure if the screen reader behaves as it should or the browsers.

[cmorten]

To complicate matters, ACCNAME isn’t the only algorithm in play for accessible name computation of HTML elements, we also have HTML-AAM section 4 to contend with.

Some relevant issues:

• Relation to HTML-AAM not obvious w3c/accname#8
• Consider adding hooks/extension points to native host languages w3c/accname#35
• Update "host name language" references with links. w3c/accname#201

Depending on the spec you use as your starting point I’m not convinced you can potentially land with different results 😅 that may simply be me lacking ability to follow!

In this specific case of a hidden <label> naming a form control, there are some relevant issues:

• Clarification of behavior for "native host language text alternative element" in step 2A w3c/accname#148
• Consider: hidden <label> can still name associated form control w3c/html-aam#370

These hint at a future intention to treat a hidden <label> with for as equivalent to aria-labelledby such that it’s accessible name is used regardless of whether it is hidden, and not to ignore it in preference of proceeding with the algorithm to deriving name from contents etc.

[alex1701c]

Thanks for all the investigation on this!