Using the file compare tool with screen readers needs some attention

[mehgcap]

Issue Type: Bug

The problem is, basically, that screen readers don't know that comparisons are happening. (I'm using NVDA for my screen reader.) In side-by-side mode, only the editable file can be browsed; I've not found a way to jump between it and the file showing the differences. In inline mode, NVDA simply jumps over any line indicating a change, making the mode useless.

The f7 command is the only way to get meaningful information about differences (side bug: f7 and shift-f7 appear to do the exact same thing). My main problems with f7 are:

• There's a confusing line of text at the top of the list that has some line numbers, then two numbers indicating something? Basically, I have no idea what the top item in the list means.
• The list includes items starting with a plus or a dash, which makes sense, but it also has a bunch of extra lines that don't appear to be different. Are these for context?
• The list items all show the line number first. If I am comparing files I know well, I don't want to hear the line number constantly. It should be at the end, so I can hear the changed line itself first.
• Once I find a change, I can't do anything with it. How can I revert the change so my file matches what the list item is showing? Pressing enter only moves me to the line, and there is no context menu for any list item.
• Sometimes, I am taken out of NVDA's mode that works well with web UIs like VS Code. I am jumped to a list of diffs that is different from the list I've been describing so far. Yesterday, I had the list I've been talking about; today, when I went to confirm some things, I wound up in this new list.

I'm not sure what a good, accessible diff editor might be like. I'd love a sound indicating an addition, removal, or change, with a keystroke to update the active file with the change from A or B, or insert both (in case of a line change) then let me edit them together. Sounds would be hard with a web UI, though, and don't do anything for braille users. Maybe a custom style that a screen reader could interpret? Also, commands to jump from change to change would be great (no, the ones in the Go menu don't do anything).

VS Code version: Code 1.41.1 (26076a4, 2019-12-18T14:58:56.166Z)
OS version: Windows_NT x64 10.0.18362
Remote OS version: Linux x64 3.16.0-4-amd64

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (4 x 3093)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: unavailable_off skia_renderer: disabled_off surface_control: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off webgl: enabled webgl2: unavailable_off
Load (avg)	undefined
Memory (System)	15.88GB (9.53GB free)
Process Argv
Screen Reader	yes
VM	0%

Item	Value
Remote	SSH: git.domain.com
OS	Linux x64 3.16.0-4-amd64
CPUs	Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz (2 x 2294)
Memory (System)	15.71GB (1.22GB free)
VM	100%

Extensions (6)

Extension	Author (truncated)	Version
remote-containers	ms-	0.94.0
remote-ssh	ms-	0.48.0
remote-ssh-edit	ms-	0.48.0
remote-wsl	ms-	0.41.7
vscode-remote-extensionpack	ms-	0.19.0
php-debug	fel	1.13.0

[isidorn]

@mehgcap thanks a lot for creating this issue and for providing this fantastic feedback.
Our idea behind F7 is for it to be an accessible way to look at Diffs. While you provided valuable feedback about improving the diff view alltogether, I would first focus on fixing the issues in the F7 experience. And once we fix those we can discuss if that make F7 useful or we would need a different approach.

1. F7 and shift + F7 doing the same -> I can reproduce
2. I agree that the top line of text does not have enought context. I believe those are line differences but @alexdima can correct me
3. Yeah the extra lines are for context
4. Reading the line numbers at the end makes perfect sense
5. For reverting a change or staging it we could introduce context menu actions. @alexdima other ideas?
6. Being taken out of NVDA mode: I do not understand this issue, this does not sound diff view specific? @mehgcap can you maybe create a brand new github issue with steps so we try to figure out what is goind on here
7. I do not believe we have Electron API to produce diferent sounds

This mielstone we have already planned, but I believe we might have time next milestone in February to try to address most of the issues you outlined.

[mehgcap]

Thanks for the quick response.

5. Keystrokes would be ideal, but a context menu is only one extra keypress, so works for me. It would be a great start, and may well end up being the best way to do this overall. I know nothing about Electron, so don't know if keystrokes can be altered while in the f7 menu.

6. I can't reproduce this consistently either. All was well when I tested compare functionality on day 1, then I ran into the problem when trying to confirm some things on day 2. If I ever figure out how this happens, I'll open a new issue.

7. That's okay. As I said, it wouldn't help braille users anyway. Plus, as you said, the f7 menu is the focus, not redoing the entire experience. In that menu, the plus and minus indicate what happened just fine.

[isidorn]

5. Yes, we would do a context menu action and probably a keybinding. We can customise keybindings any way we want and add them for any command - VS Code allows that
6. Yeah a new issue would be best thanks
7. Makes sense

We will have more details once we start workign on this in February. Thanks a lot!

[isidorn]

Unfortunetly did not have time to tackle this feature this milestone. Thus pushing to March as I plan to look into this then.