Consider adding a setting for a11y quickpick placeholder / default selected item behavior

[meganrogge]

It is great that the placeholder text can now be read by screen reader users in a11y mode. However, depending on the individual, the benefit of this is not worth it given the cost of having to arrow down to select a quick pick item any time the command palette is used.

It really disrupts muscle memory, another reason we should allow changing back to the original behavior.

I think we should make a setting so the user can decide which they prefer. We should include it in the accessibility help menu and include the @accessibility setting tag.

cc @isidorn

[TylerLeonhardt]

The original behavior is inaccessible... so it's hard for me to see the value in offering a setting to allow someone using accessibility mode specifically made for screen readers to use an experience that is inaccessible.

[meganrogge]

It depends on how you define accessible though. Because it feels inaccessible to have to use the down arrow key every time a quick pick opens and there are users out there who have physical challenges associated with pressing keys, making each keystroke important

[TylerLeonhardt]

For those users, they can turn off accessibility mode, right?

[meganrogge]

Yeah, let's see if others report this

[rperez030]

Hi team. this issue is closed but I will reply here as a way to continue the discussion. @TylerLeonhardt turning SR mode on or off is definitely not an option. as a screen reader user myself, VS Code is pretty much useless with screen reader mode off, so I would need to turn it on and off each time I want to use the quick input list. @meganrogge like @TylerLeonhardt said, I also don't see the value in adding a setting to make something inaccessible. In fact, the setting would be to choose between experiencing one problem or the other.

Both the current and the previous behavior are problematic in different ways. In my opinion, the current one after the fix for #178163 is way more harmful because it disrupts the main purpose of the component, creates a disadvantage of keyboard users which use the screen reader mode on and breaks existing user patterns. The previous behavior would theoretically affect screen reader users which have screen reader mode off, which is an unlikely scenario in the current state of things. In my opinion, the ideal solution would be one in which the widget will be the same whether screen reader mod is on or off. In this unified widget, users will be able to type in the input field and be notified about the active option without moving focus and move between the different part of the widget back and forth using the keyboard. Even if we consider the previous behavior which was less problematic in my opinion, there are still problems.

• The prompt is read the first time the widget receives focus but there is no easy way to read it again after you start typing.
• Screen readers cannot track focus in the input field due to the use of aria-activedescendant, so as a screen reader user I cannot edit what I'm typing. My workaround is to press escape and relaunch the widget if I make a mistake.
• There is an option to bind a command to a keyboard shortcut right there in the widget, but it is not easy to access that with the keyboard.

[TylerLeonhardt]

👋 Thank you for your input @rperez030 . It's really helpful. I totally agree that the new experience is degraded in some ways and you've enumerated them nicely.

As I've mentioned in the original issue, I was looking to follow this accessible pattern:
https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/

But that makes the experience slower.

One idea I had would be to focus the first element if there is something in the input....... however, one of your points already calls out a problem with that:

Screen readers cannot track focus in the input field due to the use of aria-activedescendant, so as a screen reader user I cannot edit what I'm typing. My workaround is to press escape and relaunch the widget if I make a mistake.

So I'm not sure that's the best idea. I truly believe that aria-activedecendant isn't the right tool for us... and we need another option...like the options you gave me in the original issue that I still need to explore. That's tracked here: #176081

[pawin35]

@TylerLeonhardt As a frequent screen reader user of VS Code, I've found that the ability to quickly press enter after typing one or two characters is a significant productivity boost for me. I haven't experienced any issues regarding the reading of the placeholder, but this might be because I don't often interact with extensions or dialogs that heavily rely on this particular feature.
However, the inability to quickly press enter in the 'go to' dialog and command palette has become a considerable hindrance for me. I understand and appreciate the need for finding a universally accessible solution. Still, I believe that, in the meantime, I believe that adding a temporary setting to deactivate the new behavior could help minimize productivity loss for users that rely heavily on prior behavior.

[TylerLeonhardt]

Don't worry, @pawin35, I am working on a way to get this working they way you expect without a setting :) #176081

[TylerLeonhardt]

Don't worry, @pawin35, I am working on a way to get this working they way you expect without a setting :) #176081

[pawin35]

@TylerLeonhardt Thank you for your efforts in addressing this issue - I truly appreciate it! The prospect of having a solution that meets our expectations without requiring a setting is awesome!
I'll be sure to keep an eye on issue #176081 and provide feedback once a solution has been proposed. I am excited to see the upcoming improvements that will benefit accessibility and productivity.
Please don't hesitate to reach out to me if you need any input from users like myself.

[rperez030]

👋 Thank you for your input @rperez030 . It's really helpful. I totally agree that the new experience is degraded in some ways and you've enumerated them nicely.

As I've mentioned in the original issue, I was looking to follow this accessible pattern: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/

But that makes the experience slower.

One idea I had would be to focus the first element if there is something in the input....... however, one of your points already calls out a problem with that:

Screen readers cannot track focus in the input field due to the use of aria-activedescendant, so as a screen reader user I cannot edit what I'm typing. My workaround is to press escape and relaunch the widget if I make a mistake.

So I'm not sure that's the best idea. I truly believe that aria-activedecendant isn't the right tool for us... and we need another option...like the options you gave me in the original issue that I still need to explore. That's tracked here: #176081

Thanks @TylerLeonhardt. It will likely require a number of changes to the current widget and careful testing to ensure all angles are covered. but I feel positive that it will pay off in terms of accessibility, user experience and even maintenance. If there is anything I can help with, please feel free to reach out.

[TylerLeonhardt]

@rperez030 I have a proposed fix that works nicely in NVDA, feel free to take a look at the PR #179193 and the followup question:
#176081 (comment)

[ahicks92]

I can't run this in my main env because I can't risk breaking my work environment with insiders but a quick check says that it works.

Just going to throw out a general thing if it's helpful. The official Aria patterns and WCAG etc. value accessibility over productivity. This causes problems in apps where the productivity is more important but is great for sites that you visit infrequently or for new users who aren't necessarily at programmer level. It's worth keeping that in mind when adopting a pattern because VSCode's goals are mostly the opposite of that: for programmers, who use it every day.

Perhaps that is already generally recognized but I have for example seen Windows slowly go downhil where it picks basic new computer user and drops the things that used to let me be efficient on the floor as well as many other apps--and then it never comes back. Making the new user/infrequent user trade-off is sadly becoming common and most of the resources out there that offer patterns implicitly make that trade-off, so I'm admittedly a bit touchy on this subject.

[TylerLeonhardt]

@ahicks92 just wanna call out that the insiders build is totally side-by-side install with the stable build and shouldn't mess up VS Code stable at all.

[ahicks92]

Hah, fair. Can't believe I forgot that while literally having installed insiders that way the other day.