checkboxes with "role=switch" should not require attribute "aria-checked"

[coliff]

I made a PR on the Bootstrap site to add role="switch" to the switch components but the validation tests fail.

I think that checkboxes with "role=switch" should not require attribute "aria-checked" according to: https://developer.mozilla.org/en-US/docs/Web/API/Element/ariaChecked

<div class="form-check form-switch">
  <input class="form-check-input" type="checkbox" role="switch" id="flexSwitchCheckDefault">
  <label class="form-check-label" for="flexSwitchCheckDefault">Default switch checkbox input</label>
</div>
<div class="form-check form-switch">
  <input class="form-check-input" type="checkbox" role="switch" id="flexSwitchCheckChecked" checked>
  <label class="form-check-label" for="flexSwitchCheckChecked">Checked switch checkbox input</label>
</div>
<div class="form-check form-switch">
  <input class="form-check-input" type="checkbox" role="switch" id="flexSwitchCheckDisabled" disabled>
  <label class="form-check-label" for="flexSwitchCheckDisabled">Disabled switch checkbox input</label>
</div>
<div class="form-check form-switch">
  <input class="form-check-input" type="checkbox" role="switch" id="flexSwitchCheckCheckedDisabled" checked disabled>
  <label class="form-check-label" for="flexSwitchCheckCheckedDisabled">Disabled checked switch checkbox input</label>
</div>

error: Element "input" is missing required attribute "aria-checked".
error: Element "input" is missing required attribute "aria-checked".
error: Element "input" is missing required attribute "aria-checked".
error: Element "input" is missing required attribute "aria-checked".

[cvrebert]

MDN isn't a specification; https://w3c.github.io/aria/ is a relevant specification. You indeed don't need to set any ARIA attributes on a vanilla checkbox. But you're setting the role=switch ARIA attribute on the checkbox anyway, for reasons, so it would not surprise me if that attribute has co-requisite attribute(s).

Do you have argument based on the actual spec text?

[patrickhlauke]

yes this seems to be a shortcoming of the validator, as you don't need aria-checked for native <input type="checkbox">

https://www.w3.org/TR/html-aria/#docconformance

Authors SHOULD NOT use the aria-checked attribute on input type=checkbox elements.

[...]

Note: The HTML checked attribute can be used instead of the aria-checked attribute for menuitemcheckbox, option or switch roles when used on type=checkbox.

[sideshowbarker]

<input class="form-check-input" type="checkbox" role="switch" id="flexSwitchCheckDisabled" disabled>

At https://w3c.github.io/aria/#switch the ARIA spec says that aria-checked is required for any element with the switch role.

So the checker is conforming to ARIA spec on that requirement.

Authors SHOULD NOT use the aria-checked attribute on input type=checkbox elements.
Note: The HTML checked attribute can be used instead of the aria-checked attribute for menuitemcheckbox, option or switch roles when used on type=checkbox.

As far as I can see, using role=switch with checked rather than aria-checked doesn’t conform to that ARIA spec requirement. What I see in the ARIA spec is language that explicitly requires aria-checked and that makes no exception for the case where the host language already has an equivalent like checked for aria-checked.

But it’s quite possible there’s some language somewhere in the ARIA spec that makes such an exception. If so, I’d be glad for somebody to provide a citation here.

Otherwise, without that, as far as I can see the only way for authors to reconcile with both the ARIA spec requirements and ARIA in HTML spec requirements would be to not use role="switch" on type="checkbox" inputs. Or else the ARIA in HTML spec needs to be updated to say it’s OK to use the aria-checked attribute on type=checkbox inputs with switch roles.

In other words, short of either getting some spec citation/clarification, or else an actual spec update being made, there’s no change I can make here without violating the conformance requirements of the ARIA spec.

[patrickhlauke]

/cc @scottaohara @jnurthen

[patrickhlauke]

my take here is that the ARIA spec just didn't consider the possibility of role="switch" being used on an actual input type="checkbox". in terms of what's exposed by the a11y API i believe it's exactly the same

[scottaohara]

From the note in 5.2.2 Required States and Properties and 5.2.3 Supported States and Properties
https://www.w3.org/TR/wai-aria-1.2/#requiredState

Note: A host language attribute with the appropriate implicit WAI-ARIA semantic fulfills this requirement.

Additionally, from https://www.w3.org/TR/wai-aria-1.2/#implicit_semantics, emphasis mine.

These host language features can be viewed as having "implicit WAI-ARIA semantics". User agent processing of features with implicit WAI-ARIA semantics would be similar to the processing for the WAI-ARIA feature. The processing might not be identical because of lexical differences between the host language feature and the WAI-ARIA feature, but generally the user agent would expose the same information to the accessibility API. Features with implicit WAI-ARIA semantics satisfy WAI-ARIA structural requirements such as required owned elements, required states and properties, etc. and do not require explicit WAI-ARIA semantics to be provided.

As an input type=checkbox already provides the necessary checked state, there is no reason to require aria-checked on a checkbox, even when it is provided a role of switch, as the implicit functionality / semantics of the checked state are not overwritten by this role change. This aligns with the note referenced in section 5.2.3. Furthermore, usage of the aria-checked attribute on an input type=checkbox role=switch would then mean there would be possibility of conflict resolutions that would need to be resolved.

From 8.5 Conflicts with Host Language Semantics:

Values for roles do not conflict in the same way as values for states and properties (for example, the HTML 'checked' attribute and the 'aria-checked' attribute could have conflicting values), and authors are expected to have valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed.

This all relates to issue #1122

[sideshowbarker]

Additionally, from w3.org/TR/wai-aria-1.2/#implicit_semantics, emphasis mine.

These host language features can be viewed as having "implicit WAI-ARIA semantics". User agent processing of features with implicit WAI-ARIA semantics would be similar to the processing for the WAI-ARIA feature. The processing might not be identical because of lexical differences between the host language feature and the WAI-ARIA feature, but generally the user agent would expose the same information to the accessibility API. Features with implicit WAI-ARIA semantics satisfy WAI-ARIA structural requirements such as required owned elements, required states and properties, etc. and do not require explicit WAI-ARIA semantics to be provided.

OK, thanks — I remember this now. So given that, I’ll make an update to not require aria-checked for inputs that have a checked attribute.

[XhmikosR]

@sideshowbarker was this fixed in 2021.9.2? We no longer get the failures in the upstream PR twbs/bootstrap#34824 but I didn't see any commit or message that this was fixed.

[sideshowbarker]

@sideshowbarker was this fixed in 2021.9.2? We no longer get the failures in the upstream PR twbs/bootstrap#34824 but I didn't see any commit or message that this was fixed.

I have made no fix for it that I can recall — so if it’s not still causing an error somewhere that it did before, I don’t have an explanation about why that’d be.

[XhmikosR]

Yeah, I don't get it either but we no longer get the errors for some reason...

[XhmikosR]

@sideshowbarker so, I confirmed it. Going back to 21.6.11 results in the errors, but using 21.9.2 works fine without any errors.

So, this was fixed somewhere along the way it seems.

[XhmikosR]

Maybe it was 1214126 that fixed it?

Either way, I guess you can close this issue since it doesn't happen with the latest version :)

[sideshowbarker]

Maybe it was 1214126 that fixed it?

Seems so, yeah. That was quite a while ago. I guess what confused me was that this issue was filed only a few days back. But I suppose that was probably because it was being tested against the previous NPM package, or something.

Anyway, I’m glad to know we’ve already got it working according to the spec requirements

[XhmikosR]

You released a new stable npm version only a week ago that's why :)