Check button-name failed with aria-roledescription

[EL-shadow]

Product

axe-core

Product Version

4.10.2

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

Expectation

I use attribute aria-roledescription to redefine default announce like "Button" to discernible text, example "Expandable menu"
if i just set aria-label and aria-expanded, screenreader announce excess text.

Actual

<button aria-roledescription="Aria Name" /> fail button-name check with error
https://dequeuniversity.com/rules/axe/4.10/button-name?application=axeAPI

How to Reproduce

example with button and aria-roledescription https://principled-kindhearted-oyster.glitch.me/

Additional context

I test aria-roledescription and it work in Windows NVDA , macOS VoiceOver, Android TalkBack

[WilcoFiers]

This is certainly an interesting case. There is a lot to unpack here. First up, good job testing this out. That's always an important step when working with newer ARIA features. If we do end up making a change for this we'd have to check JAWS too.

can role description provide a name?

I'm not sure I know the answer right away. I'll just write out my thought process here and I'll talk to some more people to get their view on this too. Generally, controls require both a role and a name. What you're doing with aria-roledescription changes how a role is communicated, but it doesn't set a name. This button still does not have an accessible name.

However, while WCAG requires elements to have a role & name, it does not require those to be conveyed through the correct properties in the accessibility tree. Before ARIA was widely supported (and it still isn't in some local screen readers), people used to put state information in the accessible name. Instead of using aria-current on a link someone might have add a text like (current page) to a link's accessible name. And that would be a reasonable way to provide that information. This seems similar to that scenario, which is why I'm leaning towards that this might be okay. I don't think I'd go so far as to say this passes, but maybe this should go to needs review instead of a violation.

do menus need names?

The other issue I'm seeing here is with your specific expanded menu example. ARIA already has a menu role which can be expanded. If that's the issue you're having, I don't think you need aria-roledescription. I would argue that that's probably its own failure, because you're declaring something to be a menu that isn't going to have all the other behavior of an ARIA menu, like having children that have the menuitem role. But even if you used role=menu here, that doesn't change that axe is going to fail this for not having a name.

What this has me wondering about is whether an element's role can ever be also its name. For most controls the answer is an obvious no. A link needs a name because otherwise you don't know where it goes. And just giving it the name of "link" is still insufficient because it doesn't describe its purpose. But a name of "menu" often does seem sufficient, especially if it's the only menu on the page. Kind of how if a landmark only exists once in the page it doesn't need a name to distinguish it.

So I'm kind of leaning towards saying that menus without an accessible name, if they're the only menu on the page probably shouldn't be failed. Maybe we should even just pass them.

[EL-shadow]

Thank you for your detailed answer.
I agree that this should be sent to the "requires verification" section, not the "violation" section.
I'll also try to check in JAWS and come back with the result.

[EL-shadow]

I checked in JAWS 2025
and unfortunately it announce unnecessary text "Unlabeled %number%"
I Expected "Expaned menu. Collapsed.", but instead "Unlabled zero. Expanded menu. Collapsed."

And JAWS behaves differently, on other similar buttons on the page, ignore attriubute aria-roledescription an announce it as a "Button. Collapsed"