Accessibility:MAS42A: Color is the Only Way of Indicating Changes made in a File.

[WiproPSAccTest]

VS Code Version: 1.6.1
OS Version:1607

Steps to Reproduce:
1.Open visual studio code editor.
2. Open any file and using "Ctrl+1" key navigate to the first vs code editor.
3. Using F1 key navigate to the palette, type "git branch" and "refactor-to-promise" as the branch name
4. Make changes to the code by refactoring, adding/deleting new lines ; observe any Alternative Text Description available for blue/green/red indicators suggesting if code has been changed/new line added/line has been removed.
5. Compare the changes between the HEAD and current file by navigating to View Bar ---> Git ; Navigate to changes and hit ENTER to activate "Diff View" ; Observe any Alternative Test Description available to parse code.

Expected result:
Alternative Text Description for these Color Indications should be there

Actual Result:

1. Red color Indicates -> No of lines Deleted,
   Blue Color Indicates-> No of Lines edited,
   Green Color Indicates->No of New Lines Added
2. Red color Indicates how the code was Originally and Green Color Indicates how the Code got changed to

User Impact:
Blind users might not be knowing these changes as Color is the Only Way of Indicating Changes made in a File.

Attachments:

[kieferrm]

@rebornix pls comment explaining the current state.

[rebornix]

@WiproPSAccTest and anyone interested in this issue:

Right now we are indicating modifications in two places, the gutter of the normal editor or the diff editor. For the former, we are only using colors to indicate what kind of change it is.

For the diff editor, we are using both + and - indicators and colors to indicate modifications

The + and - indicators are turned on by default and can be turned off by setting diffEditor.renderIndicators to false.

[WiproPSAccTest]

@rebornix. Alternative Text Description for these Color Indications should be there. Blind users might not be knowing these changes as Color is the Only Way of Indicating Changes made in a File.

[M-Yankov]

A Little off-topic question: Is there a way to change the background color of diff editor (added, removed lines) or I need to create a new theme? For example to make the colors brighter.

[WiproPSAccTest]

Title has been changed to a common format to perform data population.

[isidorn]

@WiproPSAccTest This has been fixed, as @rebornix pointed out we are now also showing a + or a - sign in the edior gutter. These can also be seen by color blind people.
The only issue right now is that the - and + are not being read out by the screen reader -> looing into that.

@M-Yankov it is not possible to change this. We also do not expose this colors to themes so the theme can not customize it. However the color is transparent so a different editor background has an effect here. Whether we will expose these colors to themese @aeschli is the best to answer

[aeschli]

Yes, you can change the colors and borders of the added/removed ranges using the
workbench.colorCustimizations setting. See
https://code.visualstudio.com/docs/getstarted/theme-color-reference#_diff-editor-colors for the color identifiers.

[isidorn]

After discussing with @alexandrudima the only way to improve this is to have a specail experience for browsing through all the difs in a file. Similar to the F8 experience which browses through all the errors.
Currentl the + and - are not pronounced because we have a general issue that we do not announce any editor decroations.

[alexdima]

The root problem mentioned by @isidorn above is that a <textarea> (which is what we use for the aria-role="textbox" and where we place the mirrored editor text) cannot have child dom nodes. This is not a limitation of the accessibility tree, since e.g. Visual Studio represents squiggles as children of the textbox.

In any case, I think the diff information involves more than reading the text and the decorations associated with the text. I think a diff experience should consist of:

• a way to navigate through diffs (i.e. jump from one diff to another)
• when navigating to a diff, a brief explanation is presented. e.g. Removed lines 100-110, Added 5 lines after original line 210, Modified lines 230-232.
• then, once on a diff, a key can be pressed to present a more detailed explanation. e.g. Removed code: "....". etc.
• also, once on a diff, if the modified editor is editable, a key can be pressed to focus the editor and allow for making more changes.

That's why I think this should be a more refined experience than announcing "+" or "-" on a line.

[alexdima]

It is now possible to use F7 and Shift+F7 to review diffs in the diff editor.