Remove prohibited aria-label from HasMany badge - #2217
Merged
Conversation
axe 4.13 (pulled in by a11y_audit 0.5.0) flags the unselect label of a selected HasMany badge with `aria-prohibited-attr`: a `<label>` has no corresponding ARIA role, so `aria-label` is not allowed on it and is ignored by assistive technology. The label is a pointer-only shortcut for the checkbox it points to. Screen reader users unselect an option via that checkbox in the dropdown menu, so hide the label instead. This also keeps the duplicated text out of the accessible name of the surrounding dropdown trigger, which is computed from its contents.
Flo0807
commented
Aug 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
CI on #2206 (
Update dependency a11y_audit to ~> 0.5.0) fails with one accessibility violation:a11y_audit0.5.0 ships a newer axe-core, whosearia-prohibited-attrrule now flags this. The<label>element has no corresponding ARIA role, soaria-labelis not allowed on it — and is ignored by assistive technology anyway.Fix
The offending element is the "x" of a selected badge in
Backpex.Fields.HasMany. It is a<label for=…>pointing at the option's checkbox, so clicking it unselects the option.That label is a pointer-only shortcut: labels are not focusable, so keyboard and screen reader users never reached it. They unselect an option via the checkbox in the dropdown menu instead. So the label is now hidden from assistive technology with
aria-hidden="true"rather than given a name it cannot expose.This has a second benefit: the badges live inside the dropdown trigger, which has
role="button"and therefore derives its accessible name from its contents. Previously each badge contributed a duplicated "Unselect " to that name; now the trigger announces just the selected labels.Alternatives considered:
sr-onlytext inside the label — the label is associated with the checkbox viafor, so the text would be appended to the checkbox's accessible name ("Tag Unselect Tag") and to the trigger's.role="button"on the label (asmulti_select_badgeinBackpex.HTML.Formdoes on a<div>) — would permitaria-label, but creates a button that is not keyboard focusable, and risks trippingaria-allowed-role.The
"Unselect %{label}"translation is still used byBackpex.HTML.Form.multi_select_badge, where it sits on a<div role="button">and is permitted, so no gettext changes are needed.Verification
Run locally against
a11y_audit0.5.0 (the version from #2206):Result: 3/4 passed—posts edit a11yfails with the violation above.Result: 41 passed, 325 excluded(full--only playwrightsuite; previously 40/41).Also green:
mix test(158 doctests, 447 tests, 0 failures),mix format,mix credo.Once this lands, #2206 should go green after a rebase.