-
Notifications
You must be signed in to change notification settings - Fork 29.3k
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
Comments
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. |
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 |
For those users, they can turn off accessibility mode, right? |
Yeah, let's see if others report this |
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.
|
👋 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: 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:
So I'm not sure that's the best idea. I truly believe that |
@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. |
1 similar comment
@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! |
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. |
@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: |
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. |
@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. |
Hah, fair. Can't believe I forgot that while literally having installed insiders that way the other day. |
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
The text was updated successfully, but these errors were encountered: