@chrmarti The issue is still reproduced in the VS code version.
Version: 1.44.2 (user setup)
Commit: ff91584
Date: 2020-04-16T16:36:23.138Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363

@isidorn Pushed a partial fix adding aria-label to the group elements. The links inside the group are still not read. Maybe group is not the right role. Could you advise?

We have several buttons with a header and some text in it. Two of the buttons also have links embedded. Currently these two buttons have role "group". Previously the group buttons' headers were not read, adding aria-label to them fixed this. The links are still not read and tabbing to the links shows like a secondary focus border (not sure if that is a hint towards what is going on):

@chrmarti thanks for looking into this!
I just tried it out, and at the end these guys are buttons, when you click on them they behave like buttons and they react on enter / space. Thus I suggest to use role button.

The links should also be read. So I would experiment with the aria label on the links if there is no other way for the screen reader to also make it read. You could potentialy also set role:link on them.

Using the default role 'button' seems indeed better. With this it reads the entire button's text (just like for Color Theme). When I then tab into the button, giving focus to the links, it still does not read anything. Adding aria-label to the links just makes it read the aria-label (instead of the visible text) when reading the entire button, but it remains silent when tabbing to the links themselves. Setting role 'link' on the links did not have any effect.

Clearly the behavior of the links inside the button is different from the behavior in the lists on the left of the Welcome page where they are read as expected. Embedding the links in the button in a list inside the button didn't help. I guess the screen reader tries to avoid reading the same elements twice.

I'll push the removal of the "role": "group" attributes as this seems to be an improvement and revert yesterdays change.

@isidorn Let me know if you can think of anything else I can try.

@chrmarti thanks! If you have time maybe check if NVDA or Orca behaves the same, it might be some specific VoiceOver behavior that links are not read.

Maybe @MarcoZehe has some ideas why links are handeld differently when inside a button role on macOS.

Quite simple: Buttons do not allow for interactive children. The fact that NVDA and Orca by accident do something right is nothing more than that. Buttons have text content, maybe a graphic, but never ever ever a link, other button, or form elements etc. inside of them. Never.

@MarcoZehe thanks! Might there be a better role for our use case here then. Bascicaly the whole element is clickable and behaves like a button, inside is is a text which inside it has a link.

No. What this is is a dialog, or at least a grouping, with a (yet to be added) Close button, and a link inside. This is not only a problem for screen reader users, but also for keyboard users, since theoretically, with a link inside the button, focus is in two places at once, which can never be. So, this thing needs to get a proper Close button. Clicking on the rest of the group may forward that to the Close button, except for the link, so the mouse user can still click on this and dismiss it. But still, the only proper way to do this is with a Close button.

After more discussion we decided to close this issue as fixed. The fix being the removal of the group role. That make VoiceOver read out the button's text without the need for an aria-label. Let me know if you have any concerns.

This makes sense to me Christof, thank for looking into it. If we get more specific complains in this area we can revisit this.

Verified that the entire Tools and languages and the entire Settings and keybindings buttons are read and say "button". However, as noted, the links with in each element are not read when tabbed to.