[Accessibility] Add an option to allow Alt+F5 to jump to the next --word-diff instead of the whole line

[jooyoungseo]

CC @isidorn and @meganrogge

Although Alt+F5 and F7 provide accessible diff navigation for screen reader users, it is still challenging to identify exact changes when focused on the whole line.

Could you please consider adding a setting option to allow Alt+F5 to land in --word-diff instead of the whole line so that screen reader users can more easily identify modified locations?

System Info

Version: 1.74.0-insider (system setup)
Commit: edccbd1
Date: 2022-11-16T05:24:12.776Z
Electron: 19.1.3
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: Yes

[meganrogge]

Is your thought that for a line with 3 words changed, pressing Alt+f5 would place the cursor at the start of word 1, start of word 2, start of word 3, start of word 1, and so on?

[jooyoungseo]

@meganrogge -- Exactly! As you may understand, good accessibility is minimizing cognitive load burden. That kind of navigation could improve blind programmers' productivity because we could save more time and cognitive effort and precisely get focused on exact changes upon the key press. Otherwise, we have to read through and compare between all the before and after diffs line by line, including something remaining the same.

[jooyoungseo]

For example, personally I have found the following options so useful when diffing changes in terminal:

# Display word-based changes
git diff --word-diff

# character-based changes
git diff --word-diff-regex="."

The level of customization of Alt+F5 landing point would also contribute to general usability of VSCode for sighted users as well.

However, I think blind people are more disfranchised from the benefit of git diff because line-by-line diff takes much more time for us than people imagine since we cannot take a glance.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[jooyoungseo]

Related issue: #103285 as well as this Stack Overflow question.

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[meganrogge]

@hediet I discussed your thought about how we can present word diffs in an accessible way and @jooyoungseo mentioned this issue, which would fix that.

[meganrogge]

@hediet, JooYoung suggested that once we have implemented this, it would be great if on show of the hover, we could indicate if the change was an insertion, deletion, or modification. Would that be possible?

[hediet]

it would be great if on show of the hover, we could indicate if the change was an insertion, deletion, or modification. Would that be possible?

I think it would be possible! But is certainly some work that requires planning.