TextInput leading/trailingVisual is not semantically associated with the input

[iansan5653]

TextInput supports leadingVisual and trailingVisual for rendering things into the beginning and end of the input. These are strongly visually associated with the input, but are not semantically associated at all, meaning that screen readers will only read them as part of the regular document flow. This can be confusing as the information will appear (to a screen reader) to be rendered just after the input and not associated with it, rather than inside it and directly tied to it.

This is fine for visuals that are purely decorative or redundant with the label, like many icons. But often, visuals confer important meaning onto the element. A visual might indicate:

• The currency of a number
• A keyboard shortcut that focuses the input (ref Add KeybindingHint component #4750 (comment))

Some possibilities here are already covered by other features, reducing the scope of this issue:

• Validation states: should not be indicated with visuals but rather with validationStatus prop
• Actions (like reset): should not be rendered with Visual props but rather with Action props
• Loading states: should be indicated with loading prop

It's possible that, given the few use cases (are there any others?) we should just add more props to cover the cases. Maybe a keybindingHint prop or similar would be preferable here - then we can apply the keybinding to the input label.

[TylerJDev]

Thanks for the issue @iansan5653!

I'm attempting to handle this here, #4939. We have a very similar issue reported (internal) that follows the same idea, but suggests adding it to the accessible description of the input.

I'm thinking it's best to add LeadingVisual and TrailingVisual to the description by default, as there doesn't seem to be a good way to detect if a visual contains a text alternative or not, and cases where they do not have any text alternative, the aria-describedby should be ignored by screen readers.