Change:
} const stops = container.querySelectorAll<HTMLElement>(selectors.join(', ')); if (event.shiftKey && event.target === stops[0]) { <ins> // Clear the focus from the list in order to allow // screen readers to read operations in the input box. </ins> dom.EventHelper.stop(e, true); <del> stops[stops.length - 1].focus(); </del> <ins> list.clearFocus(); </ins> } else if (!event.shiftKey && event.target === stops[stops.length - 1]) { dom.EventHelper.stop(e, true); stops[0].focus();

Discussion:
CC: Issue Type: <bBug</bNVDA running, press ctrl+p or ctrl+shift+p. Then type some text. Expected: pressing backspace or using the arrow keys reads the relevant characters as with usual edit fields when focus is on the edit field which controls the options that appear. Actual: nothing is heard VS Code version: Code - Insiders 1.47.0-insider (, 2020-06-23T09:03:35.861Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (14)</summaryExtensionVersion ------ notes1.0.1 vscode-markdownlint0.36.1 vscode-eslint2.1.5 gitlens10.2.2 prettier-vscode5.1.0 Go0.14.4 rest-client0.24.1 python2020.6. remote-wsl0.44.4 cpptools0.28.3 vsnotes0.7.1 rust0.7.8 markdown-preview-enhanced0.5.12 vscode-webhint1.5.6 </details<!-- generated by issue reporter --
I tried this out and can reproduce with NVDA. However it works just fine with Orca and VoiceOver. So I think there seems to be an issue on the NVDA side here. Is it possible to look into this from the NVDA side. Repro should be quite easy with the comments from above. We are setting to set focus on the child element so that might be confusing NVDA?
Closing this since there hasn't been any activity and says it's likely on the NVDA side.
Is there a related NVDA issue? I couldn't find one. It would be really helpful to have a test sample to ensure we look at the right thing.
Sorry for the slow response, I was on vacation last week. I have created this issue let's continue the discussion there. Thanks!
I can reproduce this with Narrator as well. I'd be curious about JAWS. As per I'm not sure whether saying this is NVDA specific is a valid conclusion, may be it is Windows specific though.
I just tried JAWS and I can also reproduce there.

So I do agree it seems like the issue is not on the NVDA side, thus let's reopen this one. What actually happens is that we use here. So the has dom focus but the screen reader because of the attribute is looking at one of the items in the list. I am not sure how this works on Orca or on VoiceOver. Since in practice / navigation leaves focus in the inputbox which has dom focus and then the characters should be read. / changes the and then the item in the list should be read. might you know how does Orca handle these "two focused items" problem? Repro: open vscode, press . Type some text. Use / arrows.
It might be good too look ath the for development guidelines. Those seem to behave correctly on Windows.
I can confirm this problem still exists.
I can also reproduce. I also tried with the Exploration build that uses the latest Chrome and I can still reproduce. can you check if we for example do not set the does this no longer repro? Just so we make sure that is the thing that confuses screen readers on Windows. Maybe we need to introduce a workaround: when the user navigates left / right in the quick pick do not set the active descendant. I still believe that the issue is on the Windows / Chrome / Screen reader side. And that NVDA should get events from Chrome if there is a cursor change on a parent of the active descendent.
This should be working now since for accessibility mode we do not set when the input box changes.
reopening as I am depending on aria-activedescendant again in
mentioned we could hook up + to remove the by maybe focusing none.
this is looking great to me. Some ideas for possible refinements. focus management. If I set focus to an element in the list, press shift +Tab and tab back to the list again, focus gets reset. In fact, it seems like the parent list receives focus at this point. There are also instances in which I need to Shift Tab twice to move focus from the list to the combobox, particularly if it is the second or third time I do it. Ideally focus would return to the item that was selected before pressing Shift +Tab.

If this is not possible, I would then suggest that Tabs behaves like Down arrow key which focuses on the first element in the list. controls accessible names and descriptions Right now, the combobox has the generic name of 'input'. NVDA calculates the accessible description based on the placeholder text but JAWS doesn't. My suggestion: We could use a more descriptive name for the combobox, maybe "filter", and use aria-description for the placeholder text. The list currently receives the accessible name from the placeholder text as we discussed, but that feels more like a description to me. suggestion: We could give the list a generic name (E.g. 'actions'), and use aria-description to communicate the placeholder text. Ideally that list will be named based on context depending on how the widget is used, but that may complicate things and open a door for future issues if it is not defined correctly. I think it would help if we could also suppress the unnecessary announcement of search results (). Like I said, even without refinements, in my opinion, this feels even better than the initial implementation. thank you very much to everyone involved
thanks for your feedback! Can you open new issues for each of these improvements so that I can tackle them independently? I'm glad it's better for you. I may have to focus on other things I own at the moment, but I want to make sure these additional improvements are captured.
Definitely. I will open separate issues. Maybe I can even tackle some of this myself with a bit of mentorship.