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

[mehgcap]

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 (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

[isidorn]

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:

• Find widget @rebornix
• Problem @sandy081
• Diff editor moving by change @rebornix

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]

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

• Find Widget
  • We can add aria support all in Find Controller

    vscode/src/vs/editor/contrib/find/findController.ts

    Lines 310 to 323 in 7100934

    	public moveToNextMatch(): boolean {
    	if (this._model) {
    	this._model.moveToNextMatch();
    	return true;
    	}
    	return false;
    	}
    	public moveToPrevMatch(): boolean {
    	if (this._model) {
    	this._model.moveToPrevMatch();
    	return true;
    	}
    	return false;

• Diff Editor
  • Add support inside Diff Navigator

    vscode/src/vs/editor/browser/widget/diffNavigator.ts

    Line 179 in 7100934

    private _move(fwd: boolean, scrollType: ScrollType): void {

[mehgcap]

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 ***@***.***> 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 <#89111?email_source=notifications&email_token=AAILC25Q2FULYGW55VYVGWTQ7FVQHA5CNFSM4KKKGRY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJW36XQ#issuecomment-577617758>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILC26IG33F2CS6VGDN6NDQ7FVQHANCNFSM4KKKGRYQ>.

[isidorn]

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

[isidorn]

@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 Using the file compare tool with screen readers needs some attention #88695

[mehgcap]

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.

2. 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();

3. 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]

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:

• See your cursor, in which case reading out the line might seem overly verbose
• know the entire file by heart , which is unlikely.

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]

@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 #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]

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 ***@***.***> 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]

@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]

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

[sandy081]

Following is read when navigated to problems using goto problems

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

Example:

Open to do changes if there are suggestions.

[isidorn]

That makes sense to me. Thanks for doing this!

[JacksonKearl]

@sandy081 PROBLEM_NUMBER of TOTAL_PROBLEM_COUNT would be helpful.

we also should do this for

• f4: workspace search @roblourens @JacksonKearl
• f7: go to next symbol @alexdima

[isidorn]

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