Screen reader announces 'value' prop instead of 'title' or 'aria-label' prop

[benbenbuhben]

Problem:

The value prop of a tree node is often a numeric id, unique hash, or other non-human-readable identifier. Currently when navigating the Tree Select dropdown using a screen reader, each option's value prop is announced instead of either the title or aria-label prop. This makes it impossible for screen reader users to understand the options being presented.

Expected behavior:

I would suggest that the screen reader prioritize which prop to announce in the following order:

1. aria-label: If provided, this should be the primary prop announced by the screen reader. It is expected to contain the most accessible and human-readable description of the node.
2. title: If the aria-label prop is not provided, the title prop should be announced since this is the actual content displayed in the dropdown. However, as the 'title' prop can be either a string or a React element, the screen reader should only announce it if it is of type string.
3. value: If neither an aria-label prop nor a suitable title prop (of string type) is provided, the value prop should be announced.

Suspected Cause:

The span element within the dropdown in OptionList.tsx, which has aria-live="assertive" applied, seems to always announce the value of the active node, even when an aria-label is present. This should be modified to instead announce the human-readable props according to the order above.

https://github.com/react-component/tree-select/blob/master/src/OptionList.tsx#L213-L215

Related issues/PRs:

ant-design/ant-design#40055 - Existing Ant Design issue related to this problem.

ant-design/ant-design#41978 - Allows aria-label prop to be passed into rc-tree-select (released in antd@5.4.6)

#413 - This open PR proposes a labelInAriaLive boolean prop, which if true would announce the title prop instead of the value prop. Although this does not account for an aria-label prop being set on the node, which should be prioritized by the screenreader first.

#426 - This PR attempted to solve this issue but was closed without being merged.