search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.67k stars 29.07k forks source link

screen readers should speak the line landed on when navigating with f3, f8, etc #89111

Closed mehgcap closed 4 years ago

mehgcap commented 4 years ago

Issue Type: Feature Request

Please consider adding a way for screen readers to speak the lin landed on when navigating with keyboard commands. For instance, you press ctrl-f, type, then press escape. Now, as you press f3 and shift-f3, you move from search result to search result. It would be helpful to hear the full line spoken that contains the result that gets focus. This holds for other navigation keys, such as moving by change, problem, breakpoint, etc.

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

isidorn commented 4 years ago

Hi Alex,

Thanks for filling the issue and I think this makes perfect sense.

We already do this when a breakpoint gets hit. Code pointer for reference. Or did you mean when you press on a breakpoint from the breakpoints view?

We need to do the same thing for:

Assigning this to next milestone so we look into adding this.

There might be a chance that all these use cases use the same underlying EditorService api and that we can maybe tackle it on that level. @rebornix @sandy081 let me know if you do not have time and I can look into your areas. Just provide pointers.

rebornix commented 4 years ago

Just in case I don't have enough capacity next month for this task, here are some code pointers:

mehgcap commented 4 years ago

Yes, basically what happens when a breakpoint is hit. Ideally, you'd press F3 or shift-f3 and hear the line landed on, with the "x of y found for..." announcement following the line. This same would happen for other navigation commands, as described in the initial issue.

-- Alex Hall

On Jan 23, 2020, at 05:20, Isidor Nikolic notifications@github.com wrote:

Hi Alex,

Thanks for filling the issue and I think this makes perfect sense.

We already do this when a breakpoint gets hit. Code pointer https://github.com/microsoft/vscode/blob/2f1419db46d4a108e72ec58043fa51188e4f67d7/src/vs/workbench/contrib/debug/browser/debugService.ts#L743 for reference. Or did you mean when you press on a breakpoint from the breakpoints view?

We need to do the same thing for:

Find widget @rebornix https://github.com/rebornix Problem @sandy081 https://github.com/sandy081 SCM moving by change @joaomoreno https://github.com/joaomoreno Assigning this to next milestone so we look into adding this.

There might be a chance that all these use cases use the same underlying EditorService api and that we can maybe tackle it on that level. @rebornix https://github.com/rebornix @sandy081 https://github.com/sandy081 @joaomoreno https://github.com/joaomoreno let me know if you do not have time and I can look into your areas. Just provide pointers.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/89111?email_source=notifications&email_token=AAILC25Q2FULYGW55VYVGWTQ7FVQHA5CNFSM4KKKGRY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJW36XQ#issuecomment-577617758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAILC26IG33F2CS6VGDN6NDQ7FVQHANCNFSM4KKKGRYQ.

isidorn commented 4 years ago

@mehgcap thanks for feedback, yes that makes sense to me. @rebornix thanks for pointers I might look into this right now.

isidorn commented 4 years ago

@mehgcap I have some questions: 1) Find widget: for me it currently nicely reads out "1 of 4 found for SEARCH_TERM at LINE:COLUMN". So for example "1 of 4 found for hello at 7:3" do you not hear this, or just just think this message should be improved to be what you proposed? 2) Problems: how do you navigate problems. Currently we designed this to be via F8 and shift + F8. Once you navigate on a line with error we simply read that error. Reading the content of that line also might be confusing. How do you suggest we improve this? Or do you navigate problems differently? 3) Move to next change does not read the whole line nicely, are you using the F7, shift + F7 experience for this? If yes we plan to improve that as part of https://github.com/microsoft/vscode/issues/88695

mehgcap commented 4 years ago
  1. I hear the message, and would like my suggestion prepended to the existing announcement.

echo "Hello world!"; hello found at line 9 column 6, 1, of 1

or something similar.

  1. Similar to above, though a setting to let the user control whether the line or problem is spoken first would be great.

doStuff(); error, undeclared function "doStuff" at line 7, column 1

or

error, undeclared function "doStuff" at line 7, column 1. doStuff();

  1. Yes, the interface for that is very different. I originally thought f7 would act like f3 or f8, not realizing it would bring up a whole separate list. If that UI is the one that will continue to be used, it wouldn't make sense to apply the idea in this issue to that.
zersiax commented 4 years ago

I agree with @mehgcap here. The reason is really because on it's own, just knowing the line and column name, while useful, doesn't give context unless you can either:

That is where Find is concerned, in any case. Ditto for the problems view, just knowing the error message is useful, but unless you know where you are in the file, which at this point you don't because you were just jumped, you won't know the context you're in that can help debug the error. The first thing someone is going to do in that instance is up arrow down arrow to read the current line they're on. If we automate that, that would save the user a step and make the info we're already providing a lot more useful.

isidorn commented 4 years ago

@mehgcap Ok, we changed the find to pronunce the following for your example from above

echo "Hello world!"; 1 of 1 found for 'Hello' at 1:2

Please note the following details: 1 )there are no commas, dotas or anything except a whitespace between the line content and the find result. Do you think we should have something here? Is there some general rule we should follow we merging different parts of tha aria label together? 2) I did not use the word "result", "line" and "column" to make it less verbose per previous feedback from users.

We can of course tune this so please provide feedback. Next week vscode insiders will have this changes so it would be great if you could try them out and let us know how it behaves now.

So for the diff editor let's stick with https://github.com/microsoft/vscode/issues/88695 Still keeping this issue open for the go to error widget. We will also look into improving that based on your feedback.

@rebornix you can checkout my changes if you would like, you can see them in the attached commit.

Thanks a lot!

mehgcap commented 4 years ago

Thanks! I agree that less verbose is better, but I'm a fan of separating things with punctuation to make it easier to hear. A comma after the line, and another between the line and column numbers, would be good. But that's just me. VSCode loves settings for everything; would it ever be possible to define the template to be spoken in a setting? "accessibility.speech.templates.focusSearchResult": "{$line}, {index} of {total}, at {lineNumber}, {columnNumber}"

This way people can set the announcement exactly how they want. Punctuation and text cues for some, compact information for braille users, less details for those who don't need them.

As the above would take a while, and may not happen at all, I'll just say I prefer commas to separate information. Thanks! Sent from my iPhone

On Feb 6, 2020, at 06:36, Isidor Nikolic notifications@github.com wrote:

 @mehgcap Ok, we change the find to pronunce the following for your example from above

echo "Hello world!"; 1 of 1 found for 'Hello' at 1:2

Please note the following details: 1 )there are no commas, dotas or anything except a whitespace between the line content and the find result. 2) I did not use the word "result", "line" and "column" to make it less verbose per previous feedback from users.

We can of course tune this so please provide feedback. Next week vscode insiders will have this changes so it would be great if you could try them out and let us know how it behvaes now.

So for the diff editor let's stick with #88695 Still keeping this issue open for the go to error widget. We will also look into improving that based on your feedback.

Thanks a lot!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

isidorn commented 4 years ago

@mehgcap that makes perfect sense. I have added commas. As for the setting, we usually only add settings if there are conflicting opinions from users. I believe the current soution might work for everybody and I would only consider adding a setting in the future if users come with good reasons why the current annoucment does not work for them.

@sandy081 leaving this item assigned to you. So it would great if the goToErrorWidget pronunces the following LINE_CONTENT, ERROR at LINE:COLUMN or the other way around, whatever you prefer ERROR at LINE:COLUMN, LINE_CONTENT

rebornix commented 4 years ago

@isidorn thanks for the ping, your changes look pretty good.

sandy081 commented 4 years ago

Following is read when navigated to problems using goto problems

${LINE_CONTENT}, Error/Warning/Info/Hint at ${LINE:COLUMN}. ${problemMessage}

Example:

image

Open to do changes if there are suggestions.

isidorn commented 4 years ago

That makes sense to me. Thanks for doing this!

JacksonKearl commented 4 years ago

@sandy081 PROBLEM_NUMBER of TOTAL_PROBLEM_COUNT would be helpful.

we also should do this for

isidorn commented 4 years ago

@JacksonKearl this all makes perfect sense. However please file a new issue. Closing this.