Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aria-disabled non-focusable descendents #1130

Open
WilcoFiers opened this issue Dec 9, 2019 · 10 comments
Open

aria-disabled non-focusable descendents #1130

WilcoFiers opened this issue Dec 9, 2019 · 10 comments
Assignees
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Milestone

Comments

@WilcoFiers
Copy link
Contributor

WilcoFiers commented Dec 9, 2019

Currently, the ARIA spec says the following about using aria-disabled to disable descendants:

https://www.w3.org/TR/wai-aria-1.1/#aria-disabled
The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.

That would suggest that in the following code snippet the textfield would not be disabled:

<div role="group" aria-disabled="true" aria-labelledby="legend">
  <div id="legend">Personal information</div>
  <div id="givenname">Given name</div>
  <div role="textbox" aria-labelledby="givenname"></div>
</div>

I checked this against Chrome and Firefox. Chrome considers the textbox disabled. Firefox seems to ignore aria-disabled on ancestors regardless of if it is focusable or not. So neither browser seem to conform to spec.

I think Chrome's behaviour is the sensible one here, as it is consistent with what the HTML specification says should happen when using native elements. In the following example the disabled attribute on the fieldset disables he input element. The input element is not focusable because of it:

<fieldset>
  <legend>Personal information</legend>
  <label for="givenname">Given name</label>
  <input type="text" id="givenname">
</fieldset>

I do not know if this "all focusable descendant elements" is intentional, but it is inconsistent with the HTML specification, and the implementation for it seems to be lacking. Would it be possible to align this with the behaviour of the disabled attribute in HTML?

@jnurthen
Copy link
Member

jnurthen commented Dec 9, 2019

the textbox in the example is focusable. If it didn't have tabindex at all then it would not be focusable.

I agree we need a change though as IMO this should work if you had

<div role="group" aria-disabled="true" aria-labelledby="legend">
  <div id="legend">Personal information</div>
  <div id="givenname">Given name</div>
  <div role="textbox" aria-labelledby="givenname"></div>
</div>

How about something like

The state of being disabled applies to the current element and all descendant elements of the element on which the aria-disabled attribute can be applied.

@carmacleod
Copy link
Contributor

"all descendant elements ... on which the aria-disabled attribute can be applied" is a bit vague, so could probably benefit from including an example in the spec - or perhaps in the APG.

Maybe also say that it's the author's responsibility to remove all interactivity from any interactive descendants (including adding html disabled to native html disableable descendants; removing tabindex="-1", which is still mouse/code focusable; disabling mouse interaction with pointer-events: none; taking the href off anchors, etc. There's probably several other tricks I'm not aware of - can look through the code for the inert polyfill to find them all. :)

@aleventhal
Copy link
Contributor

aleventhal commented Dec 9, 2019 via email

@stes-acc
Copy link

stes-acc commented Dec 10, 2019 via email

@scottaohara
Copy link
Member

disabling a group is related to the concept of disabling a fieldset (grouping) of form controls in HTML (but not disabling a form itself. e.g. <form disabled> is not allowed in HTML).

beyond that though, no, it isn't valid to disable landmarks or other regions of content.

@aleventhal
Copy link
Contributor

Chrome's current rule of propagating disabled to focusable descendants is a nice clean, easy-to-implement rule that works. I don't see the gain in propagating disabled to unfocusable descendants.

This issue is confusing because the initial example is incorrect (tabindex=-1 is focusable). Is there a way to edit the initial issue description or should we close and reopen another?

@jnurthen
Copy link
Member

jnurthen commented Aug 2, 2022

I think we just close this? Chrome's implementation (at least) is consistent with the spec.

@jnurthen jnurthen closed this as completed Aug 2, 2022
@jnurthen jnurthen reopened this Aug 2, 2022
@jnurthen
Copy link
Member

jnurthen commented Aug 2, 2022

(didn't notice the PR) so reopening

@jnurthen jnurthen added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Sep 13, 2022
@sivakusayan
Copy link
Contributor

Related: Should aria-disabled propagate to aria-activedescendants, even if they aren't technically focusable? For example, when playing around with APG's Scrollable Listbox example, I'm noticing that marking the listbox container as aria-disabled doesn't propagate to the child options in Chrome Version 120 and Firefox Version 120. However, marking any one of the options with tabindex="0" will start propagating aria-disabled.

If the answer to the question above is "no", wouldn't that bring up an inconsistency between the roving tabindex and aria-activedescendant patterns?

@pkra
Copy link
Member

pkra commented Jan 4, 2024

related: #2052

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants