2050157 - moz-visual-picker has an unexpected aria-orientation set on the fieldset element

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect, P3)

Description

[Henry Wilkes (they/them) [:henry-x]]

<moz-fieldset> allows setting aria-orientation on the <fieldset> element, and <moz-visual-picker> will set it to "horizontal".

<fieldset> has an implicit ARIA role of group, but aria-orientation is not specified as used by role="group". As such, I'm not sure it would be used by screen readers. But maybe someone on the accessibility team knows of an exception in practice.

It is supported by radiogroup, so maybe that was the intent.

Comment 1

[Tim Giles [:tgiles]]

Attachment: Bug 2050157 - Stop moz-visual-picker from setting aria-orientation on its group. r?#recomp-reviewers

The shared render path emitted moz-visual-picker's inherited "horizontal"
orientation as aria-orientation on the moz-fieldset's <fieldset>. That fieldset's
implicit "group" role does not support aria-orientation per WAI-ARIA, so the
attribute is inert.

Add a groupAriaOrientation getter (defaulting to orientation) for the render path
to bind, and override it in moz-visual-picker to return undefined.

Navigation is unaffected. The keydown handler takes its direction from the writing
direction, not orientation.

The existing test asserted the (inert) aria-orientation was present. Flip it to
assert the attribute is absent.

Comment 2

[Mark Striemer [:mstriemer]]

The orientation was originally being set on a role=radiogroup|listbox element but that role was removed in bug 2037052. Adding the role back in seems to improve a11y for me with orca turned on for visual pickers, at least of the listbox type. I think we'd be better off to add the role back in than to remove the orientation

Comment 3

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2037052

Comment 4

[Tim Giles [:tgiles]]

Restoring the role (comment #2) runs into an allowlist problem, and I want a decision on it before writing the patch.

The role has to go on the inner <fieldset> that moz-fieldset renders, since that is where aria-orientation and aria-label land. A scratch a11y test confirmed the orientation is inert on an element whose role does not support it. But ARIA in HTML permits only none, presentation, and
radiogroup on <fieldset>. listbox and tablist are not on that list. <div> takes any role.

SelectControlBaseElement derives the container role from the child role, so this splits:

Child role	Container role	Allowed on <fieldset>
radio	radiogroup	Yes
option	listbox	No
tab	tablist	No

For radio it's a single property change. For option and tab, the role has to move onto moz-fieldset’s inner <div id="inputs"> and take aria-orientation, aria-label, and aria-describedby with it. The legend then stops naming the container natively and needs an explicit aria-labelledby. That is a restructure of moz-fieldset’s shared render path, so it lands on the four consumers outside lit-select-control too, including setting-group, whose container has to stay a plain group.

Eitan, is the allowlist a hard line here, or is role="listbox" on a <fieldset> acceptable? Gecko doesn't seem to have a problem with it, and it's the mapping that shipped until May. It is document conformance rather than a WCAG failure, that's why I am asking instead of assuming.

If it is a hard line, one route is to land radiogroup here and file the option and tab mechanism separately. A plain moz-visual-picker is type="radio", so that covers what Henry reported. But :mstriemer, your Orca result in comment #2 was on listbox-type pickers, and theme-picker, profile-avatar-selector, and edit-profile-card would keep an inert aria-orientation until the follow-up landed.

:mstriemer, one thing that would help either way: did you see that improvement with the role on the inner <fieldset>, or somewhere else in the tree?

There's two things that looked like blockers but are not. The <div id="inputs"> between the container and the options is fine, because ARIA passes accessibility children through generics. And a <legend> inside a listbox is fine, because HTML-AAM gives <legend> no ARIA role for the allowed-child list to reject.

Comment 5

[Henry Wilkes (they/them) [:henry-x]]

One thing I would add, regarding using role="radiogroup", is that an accessible name is required as per the WAI-ARIA specification, unlike role="group".

Comment 6

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2037052

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Hi Tim, any updates on this?

Comment 8

[Tim Giles [:tgiles]]

I'm trying to pare this down a bit. I think we have multiple bugs wrapped up in this one and it's making it difficult for me to get the correct fix up for review. I think my plan is to land a fix for the radiogroup picker only and file follow up bugs to handle the listbox case. The fix for the radiogroup will be an improvement, but the listbox case will still be not ideal (spec-compliant).

No good estimate on when this fix will land though.

Comment 9

[Tim Giles [:tgiles]]

Attachment: Bug 2050157 - Restore select-control container roles. r?#recomp-reviewers

Bug 2037052 removed the radiogroup mapping from the moz-fieldset host,
so radio select controls expose a plain group and the aria-orientation
on the inner fieldset has no role to produce a state from.

Rather than restoring the host mapping, which would nest a radiogroup
around the inner group, moz-fieldset now takes a mapped role
property and renders it on the inner fieldset, the same way moz-card
maps role to its <article>. Select controls bind it with .role and
derive it from getChildRole(), so a moz-segmented-control driving a
named-deck keeps its tab children out of a radiogroup, and setting
deck on a live control clears the role.

radiogroup is the only one of these container roles ARIA in HTML
allows on a <fieldset>, so listbox and tablist need the role on a
different element in a follow-up.

Comment 10

[Eitan Isaacson [:eeejay]]

(In reply to Tim Giles [:tgiles] from comment #4)

Eitan, is the allowlist a hard line here, or is role="listbox" on a <fieldset> acceptable? Gecko doesn't seem to have a problem with it, and it's the mapping that shipped until May. It is document conformance rather than a WCAG failure, that's why I am asking instead of assuming.

Sorry I got to this late. It looks like you chose to not have the listbox role on the fieldset in your latest patch, so this is a moot point. But I agree that there is no clear answer here. I feel more strongly that functionally this does the right thing.

Comment 11

[Tim Giles [:tgiles]]

(In reply to Eitan Isaacson [:eeejay] from comment #10)

(In reply to Tim Giles [:tgiles] from comment #4)

Eitan, is the allowlist a hard line here, or is role="listbox" on a <fieldset> acceptable? Gecko doesn't seem to have a problem with it, and it's the mapping that shipped until May. It is document conformance rather than a WCAG failure, that's why I am asking instead of assuming.

Sorry I got to this late. It looks like you chose to not have the listbox role on the fieldset in your latest patch, so this is a moot point. But I agree that there is no clear answer here. I feel more strongly that functionally this does the right thing.

:eeejay Just so I'm 100% clear, you're saying that restoring the the listbox and radiogroup role on a <fieldset> would functionally be doing the correct thing (or just the radiogroup)? I got no issue with restoring both roles, but then we go back to the <fieldset> not allowing the tablist and listbox roles. Just want to make sure I'm understanding correctly and all.

Comment 12

[Tim Giles [:tgiles]]

Attachment: Bug 2050157 - Clear mapped attributes when they are removed. r?#recomp-reviewers

Comment 13

[Tim Giles [:tgiles]]

Attachment: Bug 2050157 - Name about:preferences radio groups. r?#settings-reviewers-rotation,#accessibility-frontend-reviewers

Without this change, these radio groups would have explicitly failed
against the [WAI-ARIA spec]
(https://www.w3.org/TR/2023/REC-wai-aria-1.2-20230606/#radiogroup) that
states an accessible name is required for role="radiogroup".

Comment 14

[Donal Meehan [:dmeehan]]

Clearing stale need-info

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/567d5a448503
https://hg.mozilla.org/integration/autoland/rev/2f0c2e1af238
Restore select-control container roles. r=hjones
https://github.com/mozilla-firefox/firefox/commit/abb5f5a6f02e
https://hg.mozilla.org/integration/autoland/rev/570bbd4af00a
Name about:preferences radio groups. r=accessibility-frontend-reviewers,fluent-reviewers,hjones,bolsson,morgan

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/2f0c2e1af238
https://hg.mozilla.org/mozilla-central/rev/570bbd4af00a

Comment 17

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that this is fixed on Firefox 157.0a1 (2026-09-02) on macOS 14.8.9.