Multiselectable listbox with checkboxes - should the checkbox require a label

[dobrinyonkov]

Hello, I am seeking guidance on implementing a pattern similar to the Listbox with multi-select capability, which can be found here: https://codepen.io/pen.

In this particular case, the aim is to display actual checkboxes instead of checkmark icons.
To ensure accessibility, for these checkboxes we're required to provide unique accessible names.

A common question arises: should the checkbox be labeled with the text of the corresponding option, or should it be hidden from accessibility mappings or something else is better?

For instance, this could be implemented as follows:

<ul>
  <li>
    <input type="checkbox" id="option1" name="option1">
    <label for="option1" id="label_option1">Option 1</label>
  </li>
  <li>
    <input type="checkbox" id="option2" name="option2">
    <label for="option2" id="label_option2">Option 2</label>
  </li>
</ul>

https://codepen.io/yonkov/pen/wvZGYya

Your insights on this matter would be greatly appreciated.

Thank you.

[JAWS-test]

role=option has Children Presentational: True.

This means that, according to the specification, all child elements have no role, i.e. only the text content is taken into account when determining the labelling of the list entry. In this respect, it does not really matter whether the checkbox is labelled or not, as the checkbox does not actually exist in the accessibility tree.

So much for the theory. In practice, however, Chrome, Edge and Firefox, for example, still send the checkboxes to the Accessibility API even though they are not allowed to do so. And the NVDA screen reader also outputs them as checkboxes (which is all wrong). Only JAWS does not output the checkboxes, even if the browsers transmit them. It would therefore be advisable to mark the checkboxes so that they are not transmitted, e.g. with aria-hidden=true.

This answer refers to your codepen example and not to the code here in the ticket (which is different because the role=option is missing from the li element)

[mcking65]

A common question arises: should the checkbox be labeled with the text of the corresponding option

Yes.

For instance, this could be implemented as follows:

<ul>
  <li>
    <input type="checkbox" id="option1" name="option1">
    <label for="option1" id="label_option1">Option 1</label>
  </li>
  <li>
    <input type="checkbox" id="option2" name="option2">
    <label for="option2" id="label_option2">Option 2</label>
  </li>
</ul>

In this case, I think it is necessary for the role="option" to be on the checkbox itself. That is the element that would receive focus. Since they are real checkboxes, they would need to be the activeElement, aria-activedescendant would not be an optimal approach.

[mcking65]

I believe we have provided fallback error correction options in the spec that allows browsers to ignore aria-hidden on elements that receive focus. I strongly advise against using aria-hidden on anything that receives focus. I know we have discussed within the last year in the ARIA WG. I don't have time to dig it up now. You may find a normative MAY in the error correction section of the editor's draft.

It might turn out to be difficult or maybe impossible to make this approach interoperable across screen readers and browsers due to the inconsistent support for specifications that @JAWS-test noted above.