Change:
}, dispose: () => { mouseOverDomEmitter.dispose(); <ins> focusDomEmitter.dispose(); </ins> hideHover(true, true); } };

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.60.0 (user setup) OS Version: Windows 10 Steps to Reproduce: through VS Code Search tab and tab through all the buttons . ( refresh , clear search results , etc. ) ( Search tab is just an example I can see the same behavior in all buttons) Expected : On the tab navigation to each of the button, the tooltip should be displayed. On escape the tooltip should be dismissed. Keyboard users will not know what is the use of the button through the icon for the button. Actual : User cannot see the tooltip when they tab into a button. They can only see the tooltip when they hover over. !
, Hey, I search to see if there is something already open but couldn't find it. I hope it is not a duplicate.
Dup of Reasons why we are not changing this still hold which I mentioned Leaving this open for tracking purposes.
GitHubTags:#A11yMAS;#A11yTCS;#Win32;#DesktopApp;#A11y_VSCode;#WCAG1.3.3;#A11ySev3;#VisualStudioCode-Win32-Apr2021;#Benchmark;#Visual Studio Code Client;#Keyboard;#CEACCReviewed;
Removing label because we got confirmation from the testing team that this can be moved to Severity 3. Reasoning why this is Severity 3 can be found
Hi , we met the same issue. In our Teams Toolkit extension, we have several buttons on tree items.

When user tab to the buttons with keyboard, tooltip will not show: ! Accessibility team has raised a Sev2 bug to us for this issue. Is it possible to fix this?
same issue seen in bug
It can be done in one line due to a contribution by the Edge team to Chromium However, loads of tooltips don't show up, eg this toolbar (top right)- ! Maybe because is on an element which inherits the attribute from a parent element. This can be reproduced on as well.
thanks for investigating. When I make that change, I don't see it working for any of the buttons. Which work for you?
Hi, iirc it worked on New Search Editor, Search (text box), Replace (text input) and the icons in the activity bar. By the way, I noticed then that is missing in the activity bar.
when I test with the above change, it doesn't work for me for any of the buttons. I looked at the docs and it should be supported. Any clue why that would be?
you need to close and reopen after making the change. Reload Window wouldn't be enough. You can also visit in Edge and it should have the same behaviour.
Thanks, yeah, I run OSS to test, which should work, but doesn't.
It looks like we'd need to move all native hovers over to using custom ones to do this.
I sent a draft PR and explained there in more detail what works and doesn't work. (Tested on Windows 10)
I am reverting this for now because we don't want multiple tooltips showing up on hover. I'll try to investigate in December.
Removing these lines, IE the custom hover, fixes the issue, but I worry about making this change so close to the release: it looks to me like we are using custom hovers all over the place because we didn't have this flag enabled before. Do you think we can consider removing those in favor of the native ones?
the custom hovers are better for accessibility as they're exposed to the screen reader. The eventual plan is to move to custom hovers throughout the workbench. Generally if the custom hover is being used a should not be present.
Partially blocked by
isn't this separate to adopting it in different places?

I would have expected us to need a focus handler to show the hover for that specific case
This can be closed when happens
Ben has adopted the custom hover in our base widgets, so this may now be easier than before?
Kai mentioned I should consider adding a delay like we have for mouse hovers here. I need to see if this is acceptable by accessibility standards.
AFAICT, the WAI-ARIA guidelines do not specify that there cannot be a delay.
it seems like this already works thanks to your changes
When I tested on native Windows explorer, I saw a delay even when using keyboard, so it seems the same delay should apply for keyboard and mouse.
Currently the mouse and keyboard delays are exactly the same which is what we want. We do not have delays where we support instant hover such as navigating between action items on a toolbar/actionbar. FYI: pressing closes the hover
awesome work!