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

Add doc fwlink and Screen Reader detected status in Alt+F1 #27833

Closed
alexdima opened this issue Jun 1, 2017 · 2 comments
Closed

Add doc fwlink and Screen Reader detected status in Alt+F1 #27833

alexdima opened this issue Jun 1, 2017 · 2 comments
Assignees
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded
Milestone

Comments

@alexdima
Copy link
Member

alexdima commented Jun 1, 2017

No description provided.

@alexdima
Copy link
Member Author

alexdima commented Jun 1, 2017

I am not sure a fwlink is needed. Perhaps the aria label should be press Alt+F1 when the accessibility support is off.

@alexdima alexdima added feature-request Request for new features or functionality accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues labels Jun 2, 2017
@alexdima
Copy link
Member Author

alexdima commented Jun 2, 2017

This issue covers the false-negative case, while #27893 covers the false-positive case.

This is mostly based on a new setting editor.accessibilitySupport:

  • 'auto' means that we will respect what Electron's API tells us <-- this is the default.
  • 'off' means that we will never be in accessibility mode, irrespective of Electron's API (this is to cover the false-positive case).
  • 'on' means that we will always be in accessibility mode, irrespective of Electron's API (this is to cover the false-negative case).

The scenario is:

A screen reader is attached to VS Code, but Electron's API does not reflect this.

  • If this ever happens in the wild, an Electron bug should be logged.
  • The idea is we have a way to workaround this (a setting), but you cannot edit that setting using a screen reader since the accessibility support is off, so we must have another way to do it.
  • I don't have any steps to get into this state, so checking what happens is a bit tricky. I simply do not start a screen reader and just inspect the dom nodes.

Please check that:

  • When the setting is set to 'auto' and no screen reader is attached, the editor has an aria label that lets the user know about the existance of alt+f1.
    • the editor does not write content to the <textarea> (use document.activeElement.value in the console)
    • alt+f1 explains the current accessibility state thoroughly.
      • you can press ctrl/cmd + H to open the docs on the accessibility page
      • you can press ctrl/cmd + E which writes editor.accessibilitySupport: "on" to the user settings: the widget needs to be closed and reopened to reflect new state, since we don't want to update the widget while the user is potentially hearing things in there. An aria alert is generated when pressing ctrl/cmd + E to let the user know of what is going on.
  • once editor.accessibilitySupport: "on":
    • the alt+f1 explains the current accessibility state thoroughly
    • the status bar permanently reflects this and the Ln,Col is permanently hidden.
    • the editor aria label has the file name, etc. (no longer the alt+f1 message)
    • the editor writes content to the <textarea> (use document.activeElement.value in the console)

@alexdima alexdima added the verification-needed Verification of issue is requested label Jun 2, 2017
@alexdima alexdima closed this as completed Jun 2, 2017
@bpasero bpasero added the verified Verification succeeded label Jun 2, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

2 participants