aria
aria copied to clipboard
w3c
aria-disabled non-focusable descendents
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?
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.
"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. :)
The default tabindex for a textfield is 0. That makes it both focusable and tabbable The tabindex=-1 overrides this and makes it not tabbable, but it's still focusable via both JavaScript and the built in click handler.
Aaron
On Mon, Dec 9, 2019 at 2:33 PM Carolyn MacLeod [email protected] wrote:
"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. :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/1130?email_source=notifications&email_token=AAKQAZSBYSYVF4TGQS7OXOTQX2MRXA5CNFSM4JYH3DM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKMJDI#issuecomment-563397773, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZSH3QGFVZPOUXPRJ5DQX2MRXANCNFSM4JYH3DMQ .
Is the concept of disabling a group also valid for content of forms and regions and landmarks? In other programming languages, when you disable a container, all members are automatically disabled, too.
- Stefan
Von meinem iPad gesendet
Am 09.12.2019 um 22:19 schrieb Aaron Leventhal [email protected]:
The default tabindex for a textfield is 0. That makes it both focusable and tabbable The tabindex=-1 overrides this and makes it not tabbable, but it's still focusable via both JavaScript and the built in click handler.
Aaron
On Mon, Dec 9, 2019 at 2:33 PM Carolyn MacLeod [email protected] wrote:
"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. :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/1130?email_source=notifications&email_token=AAKQAZSBYSYVF4TGQS7OXOTQX2MRXA5CNFSM4JYH3DM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKMJDI#issuecomment-563397773, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZSH3QGFVZPOUXPRJ5DQX2MRXANCNFSM4JYH3DMQ .
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/w3c/aria/issues/1130?email_source=notifications&email_token=AGL2T3QLOFKV5M4JWGHYVSTQX2Y2XA5CNFSM4JYH3DM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKXPVA#issuecomment-563443668, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGL2T3VAPEBZ2S5SMAJMAIDQX2Y2XANCNFSM4JYH3DMQ.
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.
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?
I think we just close this? Chrome's implementation (at least) is consistent with the spec.
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?
