[Bug] Issues with Select rendering and JAWS
- Dominant language
- TypeScript
- Stars
- 22.6k
- Forks
- 4.2k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 15
Description
### 🐞 Describe the Bug
We've gotten reports that the JAWS is unable to correctly read minimal `select` element created with Ember. Specifically, when an option is selected, the selected value is _not_ read out by the screen reader. The workaround at the moment is to use aria-selected, but this seems problematic. Either JAWS has a bug, or Ember does, and we need to figure out which.
### 🔬 Minimal Reproduction
```hbs
{{!-- This example works --}}
Alabama
California
Oregon
{{!-- This example does not work --}}
{{#each values as |value|}}
{{/each}}
```
Codepen with the first example: https://codepen.io/pzuraq/pen/oNxGvWz
### 😕 Actual Behavior
The screen reader does not read out the option label.
### 🤔 Expected Behavior
The screen reader should read out the option label.
### 🌍 Environment
- Ember: Latest
- Node.js/npm: -
- OS: -
- Browser: -
### ➕ Additional Context
We've verified that the Ember version of the select is properly updating the _properties_ that represent the selected state, and other A11y tools including the A11y tree in Chrome work properly here. The next step is to start reducing the differences between these two examples to figure out what exactly is causing the issue.
Noted differences:
1. `selected` is set the first time as an _attribute_ on the native example. It remains set as the select is updated. By contrast, the Ember example always sets the _property_, so no option will have the attribute set at any time. We should see if removing the attribute in the native example causes any difference in behavior.
2. The Ember example will create its DOM dynamically, using `document.createElement` and manually appending it, whereas the native version does not. We should try to create a select using vanilla JS to see if that impacts behavior at all.
Contributor guide
Assessment
This issue has not been assessed yet.