is there something in the way the spec is worded that makes this ambiguous?

at a high level, the attribute is allowed on anything that isn't a generic (though it doesn't make any sense at all on an element that's none, either).

Is this more of an aria practices issue for further author guidance on when this might be appropriate to use vs not?

It is not so much for which role this is a valid property. I am OK with limitations here.

It is more related to the question abut creating the rules for an exact signature in case someone uses this.

For instance, overriding a button being a default button on a page:

aria-roledescription="Default button"

or giving extensions of specialized controls built on a base role

aria-roledescription="Rating Indicator slider"

I find that OK and convenient following the pattern that if you override a base role speech output you have to put the base role string verbosed on the platform trailing as part of the definition because screen readers completely ignore the base role string in these cases in speech output. And yes, the trailing "button" or "slider" part speech output is maybe platform-dependant and needs even to be localized.

To avoid this, the ARIA group should phrase a strong expectation to all AT vendors that they should not completely OVERRIDE the default role string in the speech output but instead APPEND it at the end of the aria-roledescription speech output. Which in turn invalidates the aforementioned pattern to put the base role at the end. In other cases, applied to structural markup roles (the famous "slide " example in the ARIA spec), there is no need to do that.

As the "slider" example reveals, aria-roledescription is also used to identify complex controls. Control documentation is directly linked to that by custom role name used, and no, this is not a thing for label or description, it is an extended custom role that needs to be given in its role name realm. Tips in the Web not to use aria-roledescription at all because of the unclear situation do not help at all and irritate devs.

So, what is needed for the AT vendors is just a list of roles where base role name should be spoken at the end of the aria-roledescription and some people need to assemble this and go to the industry contacts. I am also OK with if we can expect a fomalism speaking always the base role at the end, even for sections/regions.

Regarding APG discussion - I wanted chapter about roledescription pattern in APG for several years but nothing is in yet. And I think its because the group has in details no formal consensus on this yet. That also affects examples in the ARIA spec and possible extensions of the aria-roledescription property itself.

Therefore I've put that on the F2F agenda for discussion what can be done here in a timely fashion.

Currently the spec already says:

Authors SHOULD limit use of aria-roledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.

This topic should be on a normal agenda before a TPAC agenda to find out if there is interest in the change, and to help the discussion @stes-acc you could open a PR with your proposed changes.

The above formulation in the spec is insufficient at best. I am OK with putting this into a PR for discussion in a timely fashion.

Perfect thanks @stes-acc , we will discuss it as soon as you have a PR up.

#2018 created but there was a problem with the branch merging I need help to resolve.
I think they are not correctly assigned so dear reviewer please don't approve but tell me what to do instead :(

it looks like the updates you made were to a very old instance of the spec that you then tried to pull more recent updates into. tbh it'd be a lot easier if you were to make sure to pull down the latest version of the spec and paste your specific updates into that and make a new PR, rather than try to resolve/untangle the current one.

To add to Scott's comment, I couldn't even find a commit authored by @stes-acc on the branch which makes it very hard to do anything to help ☹️

Got the point. Thanks. Since this is on agenda for tommorrow, I'll prepare a sentence here for discussion before insertion in the spec (then it becomes even more clear for the people what I want) and if decided I'll create a new pull request upon this.

The problem is that we change EITHER the spec in a way that it is stated that base role is always to be appended as part of roledescription for a special button like so:

aria-roledescription="Default button"

OR we state that

aria-roledescription="Default"

should be ONLY set but the "button" part has to be spoken in addition by AT (since it has always access to the base role mapping).

There is no way in-between, since if we opt for the former and AT decides to do the latter one day autors have to remove the redundant base role strings all over the place.

And no, forbidding aria-roledescription="Default button" is NOT the way to resolve this since this violates the intended meaning of that attribute: extending a base role with the special name of an inherited component.

So to phrase it different: should we add as part of the PR a sentence for the attribute aria-roledescription EITHER like so:

"If authors override the role announcement of active elements they have aways to append the localized base role string as part of the roledescription to ensure that base role is always recognized"

OR so:

"If authors override the role announcement of active elements by a custom role description, assistive technology should always speak the localized base role string togehter with the custom role description to ensure that base role is always recognized"

seems more like a user agents may still expose the base role string with the custom role description. or that they (AT) should provide users an option to expose the base role string along with the custom role description.

definitely not a must, so agreed there. but a flat out should is probably still a bit much. if the point is to overwrite the default role description with a different word or words, but the role will still be announced anyway, it sort of defeats the purpose of the attribute. The author might as well have put the extra role description at the end of the accessible name then, since it'd effectively do the same thing.

re: active elements, are you meaning just like focusable elements/widget roles? re: your button example? Or would this also mean that someone would need to do something like <div role=group aria-roledescription="carousel group"> or <div role=application aria-role=description="i dunno... something, application">.

I dunno, I can see some merit in AT allowing someone to opt into re-exposing the base role for instances where someone might want that. I don't think this should be an author requirement/expectation, having to re-add the name of the role they're over writing to the roledescription value. That seems needlessly redundant since that information is already available.

I dunno, I can see some merit in AT allowing someone to opt into re-exposing the base role for instances where someone might want that. I don't think this should be an author requirement/expectation, having to re-add the name of the role they're over writing to the roledescription value. That seems needlessly redundant since that information is already available.

+1 to that. Also to

.. that they (AT) should provide users an option to expose / verbose the base role string along with the custom role description.

Hey @stes-acc we actually have quite a busy agenda tomorrow, I think it would be nice to do what Scott suggested first and create a new PR!

git checkout main
git pull --rebase origin main
# make sure the last commit matches this one: https://github.com/w3c/aria/commits/main
# if you have a problem here, because there is a problem with your main branch, then you need to delete main and fetch origin and checkout main again
git checkout -b your-new-branch
# make modifications
git add index.html
git commit -m "commit msg"
git push origin your-new-branch
# make a new PR

Thanks. I just created "ariaroledeescription" branch for the PR edits.

Unfortunately I cannot execute bash scripts from company machine in public github.
Is there a respective workflow script I can execute from within github in browser?

Also I feel unconfortable how to proceed with branch edits for the PR.
Nevertheless I edited index file in the branch with proposed new text for AT support.

From this I created a new PR

#2022

with additional wording:

Assistive technologies SHOULD also provide users an option to expose / verbose the localized base role name string along with the custom role description.

Is this the right procedure?

Discussed in last week meetings: https://www.w3.org/2023/08/31-aria-minutes#t06