Page MenuHomePhabricator

Checkbox: hide the Label from the accessibility tree
Open, Needs TriagePublic


In T364929, we discussed hiding the checkbox input's label with aria-hidden: true. This would improve the keyboard navigation (specifically in Firefox) of the Table component with row selection that uses checkbox inputs to select all rows or individual rows.

Acceptance Criteria

  • Discuss the proposed solution and gather feedback (pros/cons).
  • Add aria-hidden: true to the Label inside the Checkbox component.
  • Decide if aria-hidden: true is needed for Labels in Radio and ToggleSwitch components.

Event Timeline

@Sarai-WMDE I've just tested this locally and it causes the label not to be read by VoiceOver, so I don't think it will be this simple unfortunately :/

Yeah, that makes sense. The solution of applying aria-hidden to the cdx-label cdx-label--visually-hidden cdx-checkbox__label div would be a hack potentially acceptable only in a context like the table's, where we want the visually hidden checkbox labels to also be hidden from screen readers. This wouldn't be the right approach if we wanted to improve the accessibility of the checkbox component itself since, as you mentioned, it would make the label unreachable by screen readers by default.

My first thought was that, if we want to make checkboxes more accessible in Firefox in order to inherit a better keyboard navigation in the Selectable table, then maybe we should probably reevaluate the somewhat complex structure of the checkbox component, which might be behind this issue.

BUT, after doing some tests with other checkbox components in Firefox, I think we're facing yet again a browser issue (similar to Chrome's repetition of headings). Here's a comparison of the navigation of our checkboxes and a basic MDN example using VoiceOver in Firefox. There are no differences: in both cases, it takes 4 steps to move from the first checkbox option to the next:

(In the context of table, a 5th step is added to the bulk select checkbox due to it being wrapped in a <th> that is also announced.)

Conclusion: We can either decide to let this be, or apply that contextual solution in table to handle the browser-based issue and improve navigation in the context of said component. I would go for the later to improve a11y, but I understand that this can be perceived as problematic/inconsistent. What do you think, @AnneT?