control-has-associated-label treats options of select component as labels -> false negative

[gilluminate]

A standalone select element with no associated label will pass

<select>
  <option value="ancestors">Ancestors</option>
  <option value="descendants">Descendants</option>
  <option value="all">All</option>
</select>

^ No lint errors

A custom select component with correctly associated label will fail

settings: {
  "jsx-a11y": {
    components: {
      Select: "select",
    },
  },
},

<label htmlFor="my-select">
  Change my value
  <Select id="my-select" options={options} />
</label>

^ Lint errors

...unless the rule also defines options as labels (which is not a correct)

"jsx-a11y/control-has-associated-label": [
  "error",
  { labelAttributes: ["options"] },
],

This violates accessibility rules around select components, which need a proper label association other than the options within it.

[ljharb]

A custom select component with correctly associated label

this is expected to fail, unless Select is configured to be like a select in settings.

A standalone select element with no associated label will pass

This does seem problematic, but I think a lot less so since dropdowns are already big enough to be clicked, and often have their default-selected option be a label.

[gilluminate]

this is expected to fail, unless Select is configured to be like a select in settings.

In my case, it is. Sorry if that wasn't clear. I've updated the example.

dropdowns are already big enough to be clicked, and often have their default-selected option be a label

This isn't about clickability or intent, it's about screen readers and WCAG rules. https://dequeuniversity.com/rules/axe/4.5/select-name
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value