(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• [Accessibility]A11y_VSCode_ViewDebug_Keyboard: Keyboard focus does not remain on the same tick box when checked/unchecked. (#52331)
• [Accessibility]A11y_VSCode_ViewDebug_ScreenReader: VoiceOver does not read the role of "Start Debugging" button correctly and also name is missing for "Add Configuration" combobox beside that. (#52332)
• [Accessibility]A11y_VSCode_ViewDebug_ScreenReader: Screenreader does not read the role of "Start Debugging" button correctly and also name is missing for "Add Configuration" combobox beside that. (#52302)

For this to be done the list would have to support an option to pass in the aria role similar as to how it currently allow the aria-lebel to be passed.
Since from the breakpoints view I can not style the appropriate element.
@joaomoreno thoughts?

Yeah we probably need that.

@joaomoreno would you like a PR or you want to look into it?

PR!

@isidorn
FYI
I believe the breakpoint checkboxes exist within a tree wiget. Since this uses role=tree the active descendents must have role=treeitem

There seems to the some ambiguity and inconsistency for the support of interactive elements,
within a aria tree. I have found two issues while working with the new settings editor,
the original element roles get superseded by the tree item and input box labels
do not get read correctly by the screen reader. This is my experience on Windows with NVDA.
Electron 2.x may play a role in this problem.

Ping me if you run into similar issues addressing this and want some more details.
I will also try to identify some of the accessibility issues to pick up some slack for August.

Related: #52862

@joaomoreno currently the list just has the option to pass the aria label for the whole list, not for every element.
Should we add an option aria-role which would get applied for every item, or each item would get pinged for the aria-role. In this case we would need to introduce some AccessibilityProvider the same way tree has one.
Also a pointer on where the list actually renders and would change the aria-role would be helpful.

I am doing a lot of CCing since various issues involve various people but they're all related:

@isidorn
@joaomoreno
@bpasero
@roblourens
I'm going to make an overall issue for this. I have been doing a lot of playing around working on the setting side . It has revealed several similar issues. I also found a great resource that includes some important information that the official specs are slightly ambiguous.
http://whatsock.com/training/matrices/

Both list and tree widgets have several issues associated with this.

• Both only use role=tree as the top level aria role . This alters descendent roles which can distort output
• Widget rows are always role=treeitem
• Each tree item also has the attributes for level ,position and position in set to help the reader
• My research and experimentation shows that editable/interactive elements are not clearly supported
  within a aria tree. Both descendent element roles and their labeling become unpredictable despite
  some ambiguity in the specs. I found it was implicit trees are always read-only/non- editable

as I said all do an issue for this, but here's my suggestions:

• Allow the tree widget to accept an option for the main role
• Form based roles as top-level will not require any HTML structure change
• Use above for list also
• Investigate changing the main tree operation to use the newer treegrid role/structure
  This would require HTML structure change using a table structure (grid probably small tweaks), this is explicitly editable
  and should be able to act like both or tree , list and even grid
• Determine if list widget should always be one-dimensional, with the ability to have intractable elements
  I have an experimental PR/not cleaned up yet for my solution for settings to get both roles and labels correct for the reader. For now were going to do this all within settings, but it makes sense to consider better solutions within the widgets.
  Settings: Fix aria labels using role=form. Fixes: #54836 #57127 (comment)

Trying to coerce the current tree shows a bunch of inconsistencies even if certain things work sometimes
when the spec would imply they're not appropriate the reader still try to do their job.

@cleidigh thanks for the reply, I have just discussed this with @joaomoreno and we have come up with a solution pretty similar to what you are prosposing - so we are on the same page.

1. We will add a getAriaRole to the IAccessibilityProvider of the Tree
2. We will add a IAccessibilityProvider to the List which can be passed as an option when the list is created. The IAccessiblityProvider will be able to pass the role the same way as for the tree

Those are the first steps. After we do that we can see what is also missing.
Anyways, we will not do this in endgame -> september

@isidorn

Sounds good, some thoughts:

• IMHO the main widget role option should be an enum (tree, form, section, landmark)
  arbitrary roles could cause problems
• the "branch/row" roles should be derived from the main role above, again arbitrary could cause problems

If a main role does not support particular attributes, they should be removed within the widget automatically
e.g. in a form no levels, position et cetera

Is this something you are doing or would you like me to pick it up for September since I've worked on this already?

@cleidigh do we need to get rid of the role now that we have a nicer way to do it? I tested with NVDA and it actually seems ok like this, not sure why.

@roblourens
I'll take a look at this to see if any changes are necessary.

@roblourens
I commented in the PR because I think were still missing the ability to set the role of the tree widget itself.
#59236

Unless I missing something, we can now set the role of the individual items but not the tree itself, although it looks like you can for a pure list. Whack me if I have missed something.

I can change to use the new getAriaRole callback until we see if anyone objects to me adding the role

After investigation and testing I had to revert the PR. Reason being that the VoiceOver on mac only properly reads out things for the combination of tree / treeitem roles. For list / listitem roles and for checkbox it is silent all the time.
Using checkbox on windows also keeps nvda silent.
Thus it seems it does not make sense to customize these roles since it breaks screen reader behavior
Due to this -> reopening this issue

@isidorn
cc: @roblourens
you ran into several of the things I did when working on the new settings editor which added some different ARIA requirements. I got things to work for all input types with a few games. You can see these working on both Windows and OS X. As I mentioned previously I found that there are plenty of inconsistencies in how the readers deal with input elements that are descendents of widget roles such as tree. After experimenting with a lot of different combinations I got each of the inputs to work. In the case of settings I used a primary role of form but I also had to change some of the individual element roles including checkbox.

I am more handicapped on OS X so I was not yet able to make an example there, but I just have to do similar things to what we did with settings. I think I can get this to work in the same fashion. I will play with it for October.

Check out the new settings editor with voiceover...

@cleidigh got it. Feel free to do a PR and ping me on it and we can look into it in October

Moving to november, not something for endgame

The role and 'isChecked' seem to be seen by VoiceOver, but I don't hear it read the set size or posInSet, dunno if that's an issue.