-
Notifications
You must be signed in to change notification settings - Fork 125
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
Comments
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
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 ***@***.***> 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
<#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 ***@***.***> 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
<#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 GitHub<#1130?email_source=notifications&email_token=AGL2T3QLOFKV5M4JWGHYVSTQX2Y2XA5CNFSM4JYH3DM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKXPVA#issuecomment-563443668>, or unsubscribe<https://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. 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. |
(didn't notice the PR) so reopening |
Related: Should If the answer to the question above is "no", wouldn't that bring up an inconsistency between the roving tabindex and |
related: #2052 |
Currently, the ARIA spec says the following about using aria-disabled to disable descendants:
That would suggest that in the following code snippet the textfield would not be disabled:
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:
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 text was updated successfully, but these errors were encountered: