Change:
return localize({ comment: ['Debug is a noun in this context, not a verb.'], key: 'callStackAriaLabel' }, "Debug Call Stack"); } <ins> getWidgetRole(): string { // Use treegrid as a role since each element can have additional actions inside #146210 return 'treegrid'; } getRole(_element: CallStackItem): string | undefined { return 'row'; } </ins> getAriaLabel(element: CallStackItem): string { if (element instanceof Thread) { return localize({ key: 'threadAriaLabel', comment: ['Placeholders stand for the thread name and the thread state.For example "Thread 1" and "Stopped'] }, "Thread {0} {1}", element.name, element.stateLabel);

Discussion:
Forgot to respond and got closed due to inactivity. - We don't necessarily need them to read each item, but at the minimum screen reader users need to know that these buttons exist. Even a small announcement along the lines of "tree items actions available on tab" would suffice. Repost of:
Does this issue occur when all extensions are disabled?: Yes/No VS Code Version: 1.63.2 OS Version: Win11 Steps to Reproduce: a debug session in VSCode on Narrator keyboard and navigate focus to the debug target ! Expected Result: Narrator should announce all context, including action items associated with the treeitem Actual Result: Narrator announces just the tree item text and associated action buttons
I am not convinced this should be announced. As Rob already mentioned on that issue the user can just press tab and focus onto the toolbar. We do not do this in other places that the parent element mentions all the children element inside it. Or the element that is about to get navigated to next. Let's leave this open for now to see if there is some feedback from users regarding this. For now I suggest no action.
Not announcing anything does violate accessibility standard guidelines as visually impaired users who rely on screen readers wouldn't know that there are buttons associated with each tree item. I am filing this issue on behalf of the project where our products are required to meet accessibility standards and this component has been flagged as an accessibility violation. I understand that the prioritization might differ, but I wanted to give some context behind the issue.
Agreed that "they could just hit tab and find them" is neither valid to fulfil our accessibility needs nor is it something we can expect from users who rely on navigating without seeing. As a quick fix, is there a chance to add an aria label to elements like these that announces "more functionality available" to explain to people that hitting tab will get them there?
- Instead of adding extra announcements, we could also change the type of the component to be a tree grid/tree grid item. Screen reader users should expect more content on tab if they are on a tree grid item. Any thoughts on this solution?
thanks for your creative suggestion, but a is something that is like a table and might not fit here. Check out the example here does it make sense that VS Code trees start using a role because each element might have extra content inside.

How do Screen Readers treat vs ?
The suggestion came from the Edge Accessibility team. The core idea is that the existence of interactive buttons/content should be inherent based on the role of the element which is true for a tree grid item but not a tree item. As for screen reader behavior, treegrids are announced like tables, but they also state item position and level similar to a tree item. For instance, when you enter the grid, it will say: "Entering table, 5x2... etc {contents of the row} expanded 1 of 3 level 1" From this, the user will understand that there are additional cells with content to the right (maybe just one extra cell containing the toolbar with buttons) and also that they are in a tree structure.
Thanks for clarifying. Also are you suggesting that all trees in vscode have the role? Since every tree could have additional actions inside. What's the downside of using the role? Let's see what thinks when she finds time to reply. She is the author of Orca screen reader.
tl;dr I think Tree Grid might be appropriate here. Long form: I definitely wouldn't expect interactive elements inside a normal tree view item. The two interaction models I've seen on those are: a) Put these items in the context menu. b) Have the user press Enter on the item to enter into a secondary layer where one would then tab through interactive elements. I first saw this in the old FireBug developer tools extension for Firefox, and later, while I was working at Mozilla, we also took this approach in the built-in developer tools in the HTML tree inspector. A tool bar with buttons etc. inside a tree item is certainly not Windows-Standard, and Windows standard is what most ARIA specs and authoring guidelines primarily derive from. Tree grids come more from the Linux side, where this is at least I saw them first in GNOME Nautilus. So yeah, I would lean towards a tree grid model where one would right arrow into the buttons for an item, if available, or tab to the toolbar, etc. We'd have to play with the aria-readonly property on this tree table, since some screen readers sometimes think they're editable when they're actually not, or vice versa.
thanks for chiming in, I really appreciate your expertise.

In VS Code it is pressing to get into the toolbar that is inside the tree element. Some follow up questions for everybody on this thread so we decide how to proceed further: about the Breakpoints view? This has the role and also has interactive elements inside each ? there some unintended consequences of going with the instead of the in all our trees? Or should we use the only if there are interactive elements inside? Example: Explorer does not have interactive elements, but Search does. We need to have a consistent experience across VS Code, thus these questions. fyi
is a good question. I'll consult with our Accessibility team, but my initial thoughts are that we would need to change the role from a listitem. I'm not entirely sure if the best fit is a tree grid element or another role. wouldn't change all trees to treegrids as each role has its own set of implications and ignoring that would confuse screen reader users. If all these trees are derived from the same base class, I would add a constructor argument to differentiate treegrids and trees.
Looping back for the first question - I believe a grid/grid cell role would be best for that kind of component.
Let's assign to May as I would like to experiment with these changes at the start of a milestone
I have changed the role for the whole CALLSTACK to be a for this use case and for each item to be a . So now as you say users should expect more content when they press tab. If users get delighted by this change I would be open to do this in more views.
Hey - I appreciate the fix! Unfortunately, the component that we're using in our extension is the . Would it be possible to port the same fix over to this component considering this is the actual component our accessibility team is flagging up?
every tree item has an field which your extension can use to manipulate the role or the label of each tree property. I suggest you try using that. For example you could try different roles, or to make the label more verbose as Christian Heilmann suggested here Allowing extensions to change the role of the whole custom tree is currently not possible, and if that is what you would need then I would have to discuss with Alex Ross who is currently on vacation and this would require API changes.