Why the hidden inputs?

[robin-kestrel]

RAC components are typically implemented as a <label> around a visually hidden <span> around a native <input>. This seems like a foundational feature of the architecture, but I've nowhere been able to find any documentation explaining why this is the case.

I'm currently evaluating which headless component library to use as the basis for my next project. I've implemented a simple radio group using both RAC and Headless UI; they seem to be functionally identical as far as pointer and keyboard interaction are concerned, but the Headless UI version seems to play a little better with VoiceOver.

When I turn on VoiceOver and use [command + option + right-arrow] to navigate through the Headless UI version, it reads out the following nodes:

• "foo, selected, radio button, 1 of 2" (black rectangle around first option)
• "bar, radio button, 2 of 2" (black rectangle around second option)

When I do the same with the RAC version, it reads out:

• "foo, group" (black rectangle around first option)
• "foo, selected, radio button, 1 of 2" (black rectangle around tiny region of first option)
• "end of, foo, group" (black rectangle around first option)
• "bar, group" (black rectangle around second option)
• "bar, selected, radio button, 2 of 2" (black rectangle around tiny region of second option)
• "end of, bar, group" (black rectangle around second option)

If instead of using VoiceOver's [command + option + arrow] for navigation I use just the arrow keys, it skips the groups and jumps directly from one radio button to another; this is a bit better, but then I lose the ability to inspect an option without selecting it, and the black rectangle that indicates VoiceOver focus is still drawn around a tiny region of the option instead of the whole thing.

On the whole, I'm leaning towards RAC as the most feature-complete and best designed of the libraries I've looked at, but the awkward screen reader experience gives me pause. Why is it like this? Is this a quirk of VoiceOver that isn't replicated by other screen readers? Am I using it wrong? Is there a benefit to having the hidden inputs that outweighs the awkwardness of the experience? Is it just legacy architecture? Is there something else I'm missing?

[devlzcode]

Not an answer to your question but Headless UI uses react-aria under the hood so I think it's perfectly fine to use both at the same time.

[snowystinger]

We back everything with native inputs so that autofill and form submission work.

Side note, many assistive technologies do not have a black rectangle indicator, so I think it's ok for it to be in the general vicinity. I'm seeing it around the entire radio though in our documentation https://react-spectrum.adobe.com/react-aria/RadioGroup.html#radiogroup

As for the announcements. I think Cmd + Opt + RightArrow will switch tabs in the browser. Did you mean Ctrl+Opt+RightArrow? If so, can you provide an example where it's reading off all of this? I tried it here https://react-spectrum.adobe.com/react-aria/RadioGroup.html#radiogroup but don't have anything near that level of verbosity. You might also try adjusting your verbosity in VoiceOver settings.

Which browser and version are you on?

[robin-kestrel]

VoiceOver + Firefox is not a supported combination

Huh, ok. I'm surprised to hear that, but I see that it is reflected in the documentation, so I guess that's on me.

As for the VoiceOver cursor, we're not concerned with its placement and bounding box. It's in the vicinity of the target.

I'm not trying to be difficult — and I do understand that any library of sufficient complexity is going to have these kinds of trade-offs — but doesn't this go against accessibility best practices? I realize that a user with no vision at all won't care where the box is drawn, but for a partially sighted user, I would think that accurately representing which element is currently in focus would be pretty important?

These hidden inputs can also improve accessibility for other components. Radio may be too simple to see the benefits, but the ColorArea component is a good example.

Totally understood that the hidden inputs are a requirement for some components. But why not make them optional for the components where they're not required, like switches and radio groups, for situations where native autocomplete or form submission behavior isn't being relied upon? I don't mean to keep bringing up Headless UI, but that is the approach that they take, and it seems to work pretty well.

Is it that the assumption of an underlying native input is sufficiently built in to RAC's core architecture that making it optional in some cases would be too much work, or add too much complexity and bundle bloat?

(FWIW, another advantage to the Headless UI approach is the as prop, which makes it easy to build components with an atypical DOM structure. That color wheel radio group I showed above was originally built with Headless UI's <RadioGroup as="svg"> and <Radio as="g">. To get it working with RAC, I had to restructure its internals to use non-SVG DOM elements that could be styled with CSS clip-path. I was able to fully recreate the UX of the original implementation after about a day of work, but the Headless UI version was definitely easier to build.)

[devongovett]

But why not make them optional for the components where they're not required, like switches and radio groups, for situations where native autocomplete or form submission behavior isn't being relied upon?

I think this should be pretty rare. Most form components are used in forms. Regardless, some assistive technologies work better with native inputs than aria ones as well, especially on mobile. For example, mobile screen reader gestures for swiping up and down to increment or decrement a slider only work with native inputs on some devices/browsers.

[robin-kestrel]

Most form components are used in forms.

In my use case, I'm using RAC / HUI components to build a settings panel, where changing any setting immediately affects the main body of my app, with no form submission required. Settings are also persisted to local storage, so I'm not relying on autocomplete for anything. (TBH, prior to this discussion, I hadn't even considered relying on autocomplete.) I don't think what I'm doing is particularly unusual?

I'd expect switches and radio groups, in particular, to be used outside of forms at least as often as inside them:

• Opinions on this differ, but according to (my understanding of) the conventional UX wisdom, the primary semantic difference between a switch and a checkbox is that a checkbox should be used in contexts where a secondary confirmation (e.g. a form submission) is required, and a switch should be used in contexts without such a requirement.

• Radio groups seem like the natural component to use for a variety of widgets meant to have an immediate effect, like a "light mode / dark mode / system default" picker, a "justify left / justify center / justify right" control for a rich text editor, etc.

And even when form components are used in a form, is it actually common these days to rely on the browser's built-in form submission behavior? IME, the more common pattern for modern web apps — at least ones built with React — is to implement the individual form widgets using controlled components that persist their state to some external store (either React's built-in useState or something from a state management library), and to have form submission trigger a function that uses that stored state to explicitly construct an API request. I can't say I've done a ton of enterprise web development, though, so maybe I'm completely off base here.

[devongovett]

With newer frameworks like Remix and Next.js Server Actions native form integration is becoming much more important again, since those rely on it.

Regardless, I don't really see this as a big issue. Sure the black box drawn by VoiceOver is a little off but that should not affect the usability of the control. There are other ways to see what you are focused on, including the focus ring you draw. I don't think it is worth supporting a completely different way of rendering controls with ARIA, which would need to be in addition to the native form support we already have, just to fix that small detail. Perhaps there are other ways we could look into this such as setting an absolute position on the visually hidden element so it has the same size as its parent, but that would require additional work and might break with custom styling. Definitely not something we'll have time to look into soon.

[robin-kestrel]

With newer frameworks like Remix and Next.js Server Actions native form integration is becoming much more important again, since those rely on it.

I'll look into those — thanks for the pointer!

Regardless, I don't really see this as a big issue. Sure the black box drawn by VoiceOver is a little off but that should not affect the usability of the control.

Fair enough, I suppose. 🙂

[snowystinger]

Linking answer to as

(FWIW, another advantage to the Headless UI approach is the as prop, which makes it easy to build components with an atypical DOM structure. That color wheel radio group I showed above was originally built with Headless UI's and . To get it working with RAC, I had to restructure its internals to use non-SVG DOM elements that could be styled with CSS clip-path. I was able to fully recreate the UX of the original implementation after about a day of work, but the Headless UI version was definitely easier to build.)

see discussion: #5321