Pass something besided string to getOptionLabel()?

[jkjustjoshing]

The docs for getOptionLabel indicate that the only valid return type is a string.

However, it seems like a return value of any React node will work, such as the following:

getOptionLabel={(data) => <b>{data.name}</b>}

Should/can the docs be updated to show that anything React can render is an acceptable return type?

[jkjustjoshing]

Also, if this is accepted, the DefinitelyTyped type should be updated

[jkjustjoshing]

I just realized that this breaks the aria-live region / screen reader support, since the return value for getOptionLabel is concatenated with a bunch of other strings. When that's a JSX object you get the screen reader reading [object Object] which obviously isn't good. Closing ticket.

[jkjustjoshing]

Actually, would it make sense to log a console warning if a non-string is passed? Most people probably aren't verifying that their screen readers still work, and might do what I did: try it out with some JSX, realize it works, and leave it there.

[ebonow]

@jkjustjoshing Thanks for bringing this up.

It's likely intended that the types in the documentation should be updated to return a Node. I will add a note to follow through on this.

Regarding aria-live regions, I also agree this can break screen-readers. I'd like to propose a solution and see if this sounds good to you.

1. If JSX is passed in, parent node should contain an aria-label.
2. If JSX is passed in, aria-live config should use this value.

Thoughts?

[ebonow]

I am currently looking at accessibility within react-select and these functions are critical to it working as intended. I have linked to this issue in #4407 with the hopes of getting more attention around the desired implementation and enforcement of best practices.

[ebonow]

I have updated the documentation for this prop to include concerns around accessibility in #4414 which should offer more transparency about a11y implications.