Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
meganrogge opened this issue Mar 17, 2023 · 15 comments
Assignees
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues feature-request Request for new features or functionality under-discussion Issue is under discussion for relevance, priority, approach

Comments

@meganrogge
Copy link
Contributor

meganrogge commented Mar 17, 2023

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

@meganrogge meganrogge added feature-request Request for new features or functionality accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues under-discussion Issue is under discussion for relevance, priority, approach labels Mar 17, 2023
@TylerLeonhardt
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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

@meganrogge
Copy link
Contributor Author

Yeah, let's see if others report this

@rperez030
Copy link
Contributor

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
Copy link
Member

TylerLeonhardt commented Mar 23, 2023

👋 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
Copy link

pawin35 commented Apr 4, 2023

@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
Copy link
Member

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

1 similar comment
@TylerLeonhardt
Copy link
Member

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

@pawin35
Copy link

pawin35 commented Apr 4, 2023

@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
Copy link
Contributor

👋 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
Copy link
Member

@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
Copy link

ahicks92 commented Apr 5, 2023

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
Copy link
Member

@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
Copy link

ahicks92 commented Apr 6, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues feature-request Request for new features or functionality under-discussion Issue is under discussion for relevance, priority, approach
Projects
None yet
Development

No branches or pull requests

5 participants