You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been doing testing on the support of aria-checked on native checkboxes, specifically in regards to the mixed state, but it has uncovered some irregularities I wanted to pose to the WG.
The attribute is generally ignored (as it should be per section 8.5) on native HTML checkboxes since the implicit state/functionality of the checkbox overrides the aria-checked attribute. aria-checked=mixed is an odd duck here though because HTML conveys this by the indeterminate IDL attribute - not the checked attribute dirty checked state. Firefox/Webkit appear to strictly follow section 8.5 here and ignore aria-checked=mixed on a native checkbox (which makes sense because aria-checked generally equates to the checked/unchecked state, and this section indicates that a native attribute wins out over an aria-* one. Combining mixed into this attribute scoots around HTML having indeterminate as a separate IDL attribute to the checked state). Chromium appears to not follow section 8.5 for this attribute, exposing aria-checked regardless of the actual state of the checkbox.
Chromium is wrong to be exposing aria-checked=true|false instead of the actual state of the checkbox - but through this error Chromium will expose aria-checked=mixed on a native checkbox.
Firefox/Webkit do not expose aria-checked=true|false , and instead correctly expose the actual state of the native checkbox. But do not expose aria-checked=mixed.
Per all the above, I see a few different things that could occur here:
add a note to ARIA indicating that if authors need to expose a native checkbox in the 'mixed' state, that they need to use the host language feature to do so (this is my preference).
or, i would think that a special case for aria-checked needs to be made since it has this unique feature of combining two native states into one attribute.
OR, create an aria-mixed (or similar) attribute, deprecating the mixed value from aria-checked to mitigate this special case.
The text was updated successfully, but these errors were encountered:
I’ve been doing testing on the support of
aria-checked
on native checkboxes, specifically in regards to themixed
state, but it has uncovered some irregularities I wanted to pose to the WG.The attribute is generally ignored (as it should be per section 8.5) on native HTML checkboxes since the implicit state/functionality of the checkbox overrides the
aria-checked
attribute.aria-checked=mixed
is an odd duck here though because HTML conveys this by theindeterminate
IDL attribute - not thechecked
attribute dirty checked state. Firefox/Webkit appear to strictly follow section 8.5 here and ignorearia-checked=mixed
on a native checkbox (which makes sense becausearia-checked
generally equates to the checked/unchecked state, and this section indicates that a native attribute wins out over anaria-*
one. Combiningmixed
into this attribute scoots around HTML havingindeterminate
as a separate IDL attribute to thechecked
state). Chromium appears to not follow section 8.5 for this attribute, exposingaria-checked
regardless of the actual state of the checkbox.Chromium is wrong to be exposing
aria-checked=true|false
instead of the actual state of the checkbox - but through this error Chromium will exposearia-checked=mixed
on a native checkbox.Firefox/Webkit do not expose
aria-checked=true|false
, and instead correctly expose the actual state of the native checkbox. But do not exposearia-checked=mixed
.Per all the above, I see a few different things that could occur here:
aria-checked
needs to be made since it has this unique feature of combining two native states into one attribute.aria-mixed
(or similar) attribute, deprecating themixed
value fromaria-checked
to mitigate this special case.The text was updated successfully, but these errors were encountered: