The attribute aria-disabled is not supported by the role progressbar.

[dev-agile]

I am trying to use arial-disabled attribute in the role=progressbar.
Getting error The attribute aria-disabled is not supported by the role progressbar.eslintjsx-a11y/role-supports-aria-props
i checked w3 docs and found out that role=progressbar support aria-disabled
https://www.w3.org/TR/wai-aria-1.1/#progressbar

[rpokorny]

I'm having a similar issue, but with role=list. Looking at the aria specs it appears that aria-disabled is a global state and should not be restricted on any element or role. See https://www.w3.org/TR/wai-aria/#global_states

[rpokorny]

I had a chance to look into this today. It turns out aria-disabled as a global state is deprecated in aria 1.2. It is still going to be allowed on specific roles, but progressbar and list are not among them. The aria-query package, which this plugin uses to get the information about the roles, seems to have already removed it as a global state in light of that deprecation. See https://www.w3.org/TR/wai-aria-1.2/#h-note-51

[ljharb]

Does that mean that passing tests would be sufficient to close this issue?

[rpokorny]

What's your stance on deprecated (but not removed) aria states? If they're still supposed to be supported then the current behavior is still not correct. If you're fine with dropping support for them as soon as they are deprecated though then the current behavior is correct, though I'm not sure exactly what you're asking about passing tests.

[ljharb]

Getting error The attribute aria-disabled is not supported by the role progressbar.eslintjsx-a11y/role-supports-aria-props

We'd want test coverage either supporting this error, or refuting it.

I think that in general, if browsers still support it, we probably still want to support it - but in this case, I'm not clear on what the implications are.

A PR with tests that match the current behavior, and another PR with tests that match the desired behavior, would be most helpful :-) (or just one of those, even)

[rpokorny]

A PR with tests that match the current behavior

I believe the current tests already cover the current behavior. It appears that there are already auto-generated tests for every combination of role and aria attribute, including tests that the two roles mentioned in this PR, list and progressbar, do not support aria-disabled.

[ljharb]

ahhh ok, thanks for clarifying. so would it then be accurate to say that this being warned on used to be a bug, but as of aria 1.2, it was arguably correct, because that behavior is deprecated - which means that are choice is to "close, working as intended" or "allow this combo even tho aria-query does not"?

[rpokorny]

so would it then be accurate to say that this being warned on used to be a bug

Well that would depend on whether it also behaved this way before ARIA 1.2 came out, which I don't know. This GH issue does predate the final publication date of the ARIA 1.2 Candidate Recommendation Draft though, so if the intent is to only follow finalized standards and not Editors Drafts, then yes it would seem like this used to be a bug.

which means that are choice is to "close, working as intended" or "allow this combo even tho aria-query does not"?

Yes I believe that's the choice.

[ljharb]

@Saurabh-dev15 given that the updated standard deprecates this behavior, are you content to consider this "working as intended"?