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 alert as option instead of audio cue for components #195282

Closed
meganrogge opened this issue Oct 10, 2023 · 8 comments · Fixed by #201328 or #201833
Closed

Consider alert as option instead of audio cue for components #195282

meganrogge opened this issue Oct 10, 2023 · 8 comments · Fixed by #201328 or #201833
Assignees
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues accessibility-signal Issues pertaining to accessibility signals feature-request Request for new features or functionality insiders-released Patch has been released in VS Code Insiders on-release-notes Issue/pull request mentioned in release notes on-testplan

Comments

@meganrogge
Copy link
Contributor

@jooyoungseo and @rperez030 brought to my attention the fact that audio cues might not be practical for certain users.

We should consider adding alert when audio cues are disabled for various features.

@meganrogge meganrogge self-assigned this Oct 10, 2023
@meganrogge meganrogge added accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues feature-request Request for new features or functionality labels Oct 10, 2023
@meganrogge meganrogge added this to the On Deck milestone Oct 10, 2023
@rperez030
Copy link
Contributor

I agree. Breakpoints, errors and warnings come to mind. I would also add that audio cues and screen reader alert probably shouldn't be seen as mutually exclusive. For example, one thing I love about the diff view experience is the multimodal feedback. For example, when I move cursor to an inserted line, I get the ascending tone, the plus sign in my Braille display and the screen reader telling me "modified line", all of that at once. I have no way to get it wrong. Even with audio cues enabled, I've never managed to tell the difference between errors and warnings. If I hear the 2 audio cues together i can tell the difference, but don't ask me five minutes later. Is that a me thing? Maybe something to investigate.

@meganrogge meganrogge modified the milestones: On Deck, December 2023 Nov 6, 2023
@meganrogge meganrogge added the accessibility-signal Issues pertaining to accessibility signals label Dec 4, 2023
@meganrogge meganrogge modified the milestones: December 2023, On Deck Dec 4, 2023
meganrogge added a commit that referenced this issue Dec 20, 2023
@meganrogge
Copy link
Contributor Author

@rperez030 and @jooyoungseo, should we have the alerts for breakpoint on line, error on line, and warning on line on by default?

@jooyoungseo
Copy link

I think we can turn on the alert by default, allowing users to turn off if needed.

@rperez030
Copy link
Contributor

A resounding yes from me!!! I need to catch up with this thread, but I wonder if "on line" is really necessary. to me "error, warning and breakpoint followed by an empty space should be enough. This is something we should test very carefully in all the platforms with all screen readers before it hits production.Super happy to help with that in January.

@meganrogge
Copy link
Contributor Author

@jooyoungseo and @rperez030 do you think this is something users will want to configure per audio cue/ alert? I worry that's a lot of settings to have to manage for the user. Perhaps there should be one overarching setting with values of audioCue, alert, or none, or both. Thoughts?

@meganrogge
Copy link
Contributor Author

meganrogge commented Jan 3, 2024

Edit, the setting would be something like alertEnabled: true/false similar to what we do for audio cues, only this would apply across the board.

The only exception would be for the format, save audio cues, which already have their own settings for alerts and cues because of the user gesture configuration.

@meganrogge
Copy link
Contributor Author

meganrogge commented Jan 3, 2024

Note that we will not have such settings for inline suggestion, chat response pending, or chat response received as the inline suggestion should always be alerted, response pending is not needed IMO, and response received is indicated via an alert of the response.

The diff line modified, deleted, and inserted also does not need a setting as the + and - signs are not verbose.

@VSCodeTriageBot VSCodeTriageBot added unreleased Patch has not yet been released in VS Code Insiders insiders-released Patch has been released in VS Code Insiders and removed unreleased Patch has not yet been released in VS Code Insiders labels Jan 3, 2024
@meganrogge meganrogge reopened this Jan 5, 2024
@meganrogge
Copy link
Contributor Author

this was reverted for re-engineering

@VSCodeTriageBot VSCodeTriageBot removed the insiders-released Patch has been released in VS Code Insiders label Jan 5, 2024
@VSCodeTriageBot VSCodeTriageBot added the unreleased Patch has not yet been released in VS Code Insiders label Jan 9, 2024
@VSCodeTriageBot VSCodeTriageBot added insiders-released Patch has been released in VS Code Insiders and removed unreleased Patch has not yet been released in VS Code Insiders labels Jan 10, 2024
@meganrogge meganrogge modified the milestones: On Deck, December / January 2024 Jan 22, 2024
@meganrogge meganrogge added the on-release-notes Issue/pull request mentioned in release notes label Jan 26, 2024
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 accessibility-signal Issues pertaining to accessibility signals feature-request Request for new features or functionality insiders-released Patch has been released in VS Code Insiders on-release-notes Issue/pull request mentioned in release notes on-testplan
Projects
None yet
5 participants
@jooyoungseo @meganrogge @rperez030 @VSCodeTriageBot and others