Disabled options lacks HTML attribute `disabled`

Current results: When isOptionDisabled prop is present, it disables all selecting option value events (click, keyboard), but does not apply indication of the element being disabled aside from a different CSS class to the HTML element. This complicates integration testing efforts using tools such as @testing-library/react as there are no reliable HTML attributes to assert on.

Expected results: If option is disabled, an attribute disabled should be attached to the HTML element of the option

Potential issues According to W3Schools, only a small set of HTML tags natively support disabled and <div> (which is currently used for options) is not one of them. I’m uncertain what effects adding the attribute disabled to a <div> will have and I’m certain there’s a good reason for each option not being an <option> instead.

Thanks to audriusnavickasDB for providing a blueprint to this MR.

Codesandbox example: https://codesandbox.io/s/xenodochial-https-nnlgx?file=/example.js

[Rall3n]

Wouldn’t the use of aria-role="option" and aria-disabled="true" suffice for this use case? Shouldn’t cause any major incompatability with customization.

[ebonow]

Wanted to do a bit of research on this to respond to this ticket appropriately.

TLDR; closing issue, disabled attribute is not applicable, may address aria-role, aria-disabled in other a11y PRs

@johannesleander

“I’m uncertain what effects adding the attribute disabled to a <div>”

disabled is not a valid attribute for a div element: source

The disabled attribute is supported by <button>, <command>, <fieldset>, 
<keygen>, <optgroup>, <option>, <select>, <textarea> and <input>.

@johannesleander

I’m certain there’s a good reason for each option not being an <option> instead.

The options are generated inside a div (and are divs themselves to allow more customization than a standard select option). That said, an Option element is only allowed as a child from any of the following: source

Contexts in which this element can be used:
As a child of a select element.
As a child of a datalist element.
As a child of an optgroup element.

@Rall3n

Wouldn’t the use of aria-role="option" and aria-disabled="true" suffice for this use case? Shouldn’t cause any major incompatibility with customization.

Yes. This seems like the appropriate answer given the information above. It should fit in with the existing accessibility PRs we have should we decide to incorporate it into the library as it would also be more consistent with how disabled options are treated in react-select (perceivably disabled and still focusable): source

Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable.

For example, irrelevant options in a radio group may be disabled. Disabled elements might not receive focus from the tab order. For some disabled elements, applications might choose not to support navigation to descendants. In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled.

The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.

The other question though, is this something a user can implement today? Yes.

const Option = props => {
  const innerProps = { ...props.innerProps, 'aria-disabled': props.isDisabled, 'aria-role': 'option' };
  return <components.Option {...props} innerProps={innerProps} />
}

So yes, a select DOM element can contain disabled options ~which make them unfocusable~. While we would like to make every attempt to be consistent, the HTML standards do not fit in this use case. There is an argument to make disabled options as non-focusable, but that feature request exists as another ticket already #3902

In further research, it seems that the origin of making disabled options focusable is based in accessibility and that indeed select options are focusable when using VoiceOver.

That all said, it seems appropriate to close this ticket out, but we can of course re-open if anyone has further thoughts or thinks this needs more review.