Accessibility getting started experience

[meganrogge]

I had a conversation with @kieferrm and we are seeking feedback from the community about the screen reader experience in VS Code.

Some questions:

How was your getting started experience and how can we improve it?

There are many visual elements to VS Code - the activity bar, the file explorer, etc. Is tabbing around all of those elements useful or would it be preferable to have a custom profile where those are hidden by default?

We could detect that a screen reader is being used and open this profile - then read the accessibility help page or a richer one with additional info. What info do you wish you had been told when you first got started?

Are there examples of applications that have a good getting started experience or easy to use layout with only the useful components?

[isidorn]

I love these questions!
Also I like the idea of using profiles as a way to customise the vscode accessibility experience.

How would you like to proceed here? We could for example create a survey and send it to program-l mailing list?

[meganrogge]

That sounds great 👍🏼. Should we start with the questions in this issue or break them down further?

[isidorn]

@meganrogge sorry for the slow response. I think we can start with these questions.
@digitarald how do we usually create surveys? Do we use surveymonkey? Do you have some advice here?

[digitarald]

@digitarald how do we usually create surveys? Do we use surveymonkey? Do you have some advice here?

Surveymonkey works great, but Microsoft Forms might also be a solution for a quick and short survey.

[meganrogge]

Will our audience have access to Microsoft forms? I have not used that before

[jooyoungseo]

If you are interested, I am willing to collaborate with your team to pursue these kinds of questions as part of my research project. But, please feel free. Just chiming in to let you know that I am here to help out.

[meganrogge]

That would be fantastic! Perhaps we could set up a meeting to discuss this sometime next week?

[jooyoungseo]

@meganrogge -- I have sent you an email off this thread.

[meganrogge]

@isidorn and I discussed this and we're thinking that we shouldn't create a separate profile as we want to keep the experience the same.

When a screen reader is detected, we could have a getting started experience specific to screen reader users based on what our research shows to be the most important points of operating VS Code.

[isidorn]

The interesting question is what would be a part of that "accessibility getting started" page. What is missing in the regular getting started walkthrough that could benefit screen reader users?

[meganrogge]

Yes and does the existing getting started walkthrough benefit screen reader users?

[meganrogge]

Some people like to learn through their own discovery:

• For example, when you focus a terminal, you hear how to access the terminal accessibility help menu and doing so keeps your current context.
• Which other VS Code features or extensions would benefit from their own accessibility help menu or aria label hint?

Some people like to have a walk through:

• We could have a getting started accessibility walk through that would point to all of the features that have their own help menu / contribute an aria label hint
• Extensions could contribute to this (Copilot for example)

[meganrogge]

as for the discovery component, we want to make sure we're not annoying to users who have already been informed

to prevent this, we could introduce a setting like accessibiltyHelp.verbose which dictates whether or not that is applied to the aria label.

for example:
accessibilityHelp.verbose

• terminal
• diff editor (use Shift + F7 to navigate changes )
• editor
• explorer
• copilot

[meganrogge]

Would love any feedback @isidorn @jooyoungseo @jvesouza

[meganrogge]

We could also have a command that allows disabling the verbosity from a particular context. So, for example, if I'm in a diff editor, I run Accessibility: reduce verbosity and it switches the diffEditor setting off.

[isidorn]

I think having an accessibility walkthrough is a great first step here.
Would that walkthrough appear always or only when we detect a screen reader?

I do not fully understand the idea behind accessibiltyHelp.verbose - can you clarify?

[meganrogge]

Yes, when you focus a diff editor, the screen reader announces, Use shift+f7 to navigate changes. Or, when you focus the terminal, you hear Use alt+f1 for terminal accessibility help. This is great for most users because of discoverability and context aware help, but would get annoying quickly for more experienced users.

As such, it would be nice if this setting allowed you to opt-out of these aria hints on a per feature basis.

[meganrogge]

I created this issue to track that awhile ago #172465

[isidorn]

I see, thanks! I think we can do that as part of #172465
Especially if we hear from users that those announcements are annoying. We could send an email to program-l to ask for feedback on this topic.

[jvesouza]

I see, thanks! I think we can do that as part of #172465 Especially if we hear from users that those announcements are annoying. We could send an email to program-l to ask for feedback on this topic.

Personally I would love it if I can configure VSCode to no longer announce the help when I move focus to the terminal.

[jooyoungseo]

Yes, I also would like to mute the hints in terminal and diff editor. No need to hear that info.

[meganrogge]

Since we will leave these on by default with beginners in mind, I think the consensus of our power users, @jooyoungseo and @jvesouza, is sufficient to proceed with this 😄

[meganrogge]

I had forgotten about this issue! Since we now have the accessibility verbosity settings, accessible view, and accessibility help dialogs, I'm closing this.