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:

1. 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).
2. 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.
3. OR, create an aria-mixed (or similar) attribute, deprecating the mixed value from aria-checked to mitigate this special case.