Change:
this._hover.containerDomNode.focus(); } hoverData.colorPicker?.layout(); // The aria label overrides the label, so if we add to it, add the contents of the hover <del> const accessibleViewHint = getHoverAccessibleViewHint(this._configurationService.getValue('accessibility.verbosity.hover') === true && this._accessibilityService.isScreenReaderOptimized(), this._keybindingService.lookupKeybinding('editor.action.accessibleView')?.getAriaLabel() ?? ''); </del> <ins> const hoverFocused = this._hover.containerDomNode.ownerDocument.activeElement === this._hover.containerDomNode; const accessibleViewHint = hoverFocused && getHoverAccessibleViewHint(this._configurationService.getValue('accessibility.verbosity.hover') === true && this._accessibilityService.isScreenReaderOptimized(), this._keybindingService.lookupKeybinding('editor.action.accessibleView')?.getAriaLabel() ?? ''); </ins> if (accessibleViewHint) { this._hover.contentsDomNode.ariaLabel = this._hover.contentsDomNode.textContent + ', ' + accessibleViewHint; }

Discussion:
Type: <bBug</bWhen navigating the UI using the keyboard, NVDA reads the announcement related to the accessible view before the controls that receives focus. I'm finding this to be quite a bad experience, and potentially a big issue for more beginner users of the editor. An easy way to reproduce the problem is by pressing F6 from the editor to focus the status bar and use the arrow keys to move between elements. The issue only seems to affect NVDA at the moment. It may be good to give some time to fire these updates after the control receives focus, especially if the user is navigating quickly through nearby controls like in the status bar. In fact, I wonder what is the benefit of showing just the name of controls and potentially some descriptive text in the accessible view. VS Code version: Code - Insiders 1.85.0-insider (, 2023-12-01T19:00:32.802Z) OS version: WindowsNT arm64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for the report. It shouldn't be reading info about the accessible view in this case.
last iteration, for keyboard only users, we support for showing the tooltip on keyboard focus of status bar items. I had only tested this with a screen reader on macOS. I'll be curious to see why this is causing an issue on windows.
I'm debugging with NVDA. Each time an element in the status bar gains focus, NVDA reports a liveRegionChange associated with the announcement "Inspect this in the accessible view with Alt+F2". If I press alt +F2, the name of that control appears in the accessible view.The live region update is taking precedence over the focus changed event. The same announcement is present on the mac, but over their voiceover is prioritizing the focus event over the live region update, so the control that receives focus is announced first. The same happens with JAWS in windows.
To verify, on windows, enable NVDA. Focus the status bar / activity bar. Use arrow keys. Verify that there's no message about opening the accessible view. Focus a hover in the editor using only the keyboard. Verify that you do hear a message about opening the accessible view.
This was verified in insider's by Will leave it without the label to also verify in the stable build.