The default ariaLiveMessages implementation should use an option's aria-label if it is defined

We have a usage of react select where the options are a nested object (contain an SVG image, text, and a tooltip trigger). The default implementation of ariaLiveMessages uses an option's label as the text to display, so this results in an unusable experience for a screen reader.

I have worked around the issue by defining an aria-label for the option and registering custom callbacks for ariaLiveMessages that leverage aria-label. However, I believe that the default ariaLiveMessages implementation should use aria-label instead of label (if the aria attribute is defined) to prevent this issue in general.

Example RSelect code:

onFocus: function onFocus(props) {
    var context = props.context,
        focused = props.focused,
        options = props.options,
        _props$label2 = props.label,
        label = _props$label2 === void 0 ? '' : _props$label2,
        selectValue = props.selectValue,
        isDisabled = props.isDisabled,
        isSelected = props.isSelected;

    var getArrayIndex = function getArrayIndex(arr, item) {
      return arr && arr.length ? "".concat(arr.indexOf(item) + 1, " of ").concat(arr.length) : '';
    };

    if (context === 'value' && selectValue) {
      return "value ".concat(label, " focused, ").concat(getArrayIndex(selectValue, focused), ".");
    }

Example of custom code:

const onFocusAria = ({ focused, isDisabled }) => {
    return `${isDisabled ? 'Disabled option ' : 'Option '}${focused['aria-label']}, focused.`
  }

Resulting in:

Start at the default ariaLiveMessages implementation, especially the onFocus path shown in the issue, and inspect how focused options expose label and aria-label values. Verify the behavior with an option containing nested content and an aria-label; done means the default announcements use aria-label when defined while preserving label otherwise.