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.

Sign up for GitHub

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

Jump to bottom

"Screen Reader detected" appears without using a screen reader #27893

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

"Screen Reader detected" appears without using a screen reader #27893

alexdima opened this issue Jun 2, 2017 · 16 comments
Assignees
@alexdima
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues bug Issue identified by VS Code Team member as probable bug important Issue identified as high-priority info-needed Issue requires more information from poster verification-needed Verification of issue is requested verified Verification succeeded
Milestone
May 2017

Comments

@alexdima
Copy link
Member

alexdima commented Jun 2, 2017

Extracted from @Tyriar in #27698 (comment)

I don't have a screen reader as far as I know on my Windows machine yet it's still there, removing my line/col information, bright green and in my face? As someone who has never used a screen reader on this machine I don't know how to disable the message.
@alexdima alexdima added bug Issue identified by VS Code Team member as probable bug important Issue identified as high-priority labels Jun 2, 2017
@alexdima alexdima self-assigned this Jun 2, 2017
@alexdima alexdima added this to the May 2017 milestone Jun 2, 2017
@alexdima alexdima mentioned this issue Jun 2, 2017
Closed
@alexdima alexdima added the info-needed Issue requires more information from poster label Jun 2, 2017
@alexdima
Copy link
Member Author

alexdima commented Jun 2, 2017

@Tyriar Do you perhaps use any software on this machine that behaves like a Screen Reader ? Do you do anything special that makes Electron enter accessibility mode or does Electron enter it on start-up? My best guess is that there must be some software on your machine that sends automation / accessibility events to VS Code, kicking Electron into entering accessibility mode.

Can you confirm that Chromium is in accessibility mode when this happens via the Help > Accessibility Options menu item. What software do you have running on this machine?

@alexdima
Copy link
Member Author

alexdima commented Jun 2, 2017

@Tyriar are you 100% certain you didn't have NVDA running. e.g. I think this happened once to @bpasero where NVDA was running (and "hidden" in the task bar next to the clock), and without enabling sounds in a VM one would not even notice.

@alexdima alexdima added the accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues label Jun 2, 2017
alexdima added a commit that referenced this issue Jun 2, 2017
@alexdima
Have other places respect editor.accessibilitySupport (#27833, #27893)
9caf8d7
@alexdima alexdima mentioned this issue Jun 2, 2017
Closed
@alexdima alexdima added the verification-needed Verification of issue is requested label Jun 2, 2017
@alexdima
Copy link
Member Author

alexdima commented Jun 2, 2017 •
edited

This issue covers the false-positive case, while #27833 covers the false-negative 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 NOT attached to VS Code, but Electron's API tells us that a screen reader is attached

  • 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), such that you can turn off anything we do for screen readers if you are not using a screen reader.
  • One posible way to get into this state is on Windows to start NVDA and then close NVDA. Electron does not let us know when a screen reader is detached on Windows (separate issue "Screen Reader detected" doesn't go away after closing the screenreader #27698) and we remain in this mode.

Please check that:

  • When the editor is in this mode, the label at the bottom helps you get out of this mode (i.e. it has a tooltip)
  • once editor.accessibilitySupport: "off":
    • even attaching a Screen Reader will not change anything (nothing in the status bar, nothing in the editor textarea value). However:
      • the editor aria label tells about alt+f1.
      • the alt+f1 explains the current accessibility state thoroughly
      • there is an "emergency" way to turn on accessibility support via ctrl/cmd+e in case the setting was turned off by accident.

alexdima added a commit that referenced this issue Jun 2, 2017
@alexdima
Guide the false-positive case towards the setting (#27893)
2602410
@alexdima alexdima closed this as completed Jun 2, 2017
alexdima added a commit that referenced this issue Jun 2, 2017
@alexdima
Improve tooltip (#27893)
1d65268
@bpasero bpasero added the verified Verification succeeded label Jun 2, 2017
@Tyriar
Copy link
Member

Tyriar commented Jun 2, 2017

@alexandrudima

Do you perhaps use any software on this machine that behaves like a Screen Reader ?

OneNote and maybe Dashlane would be the only things that comes to mind that may poke such APIs. This machine also has a touch screen and en, ja, zh and ko keyboard layouts active.

Do you do anything special that makes Electron enter accessibility mode or does Electron enter it on start-up?

It happens on start up.

are you 100% certain you didn't have NVDA running.

It's not in programs and features and I'm pretty sure I've never installed it

The tooltip and setting is fine for me, just hope that my case isn't too common.

@alexdima
Copy link
Member Author

alexdima commented Jun 6, 2017

I hope so too. I have OneNote installed and I don't think that's it.

The interesting thing is that:

  • the setting can stop us from doing anything accessibility related, but the setting does not stop Chromium.
  • it is my experience that Chromium is very slow when it enters accessibility mode.

@Bill-Stewart
Copy link

I have the same problem. I do not have any screen reader software. I had to manually set editor.accessibilitySupport to off.

@Tyriar
Copy link
Member

Tyriar commented Jun 21, 2017

@Bill-Stewart can you think of any software you have that could be pretending to be a screen reader?

@Bill-Stewart
Copy link

Bill-Stewart commented Jun 21, 2017 •
edited

No idea whatsoever. How does electron determine that there's a screen reader?

@alexdima
Copy link
Member Author

@Bill-Stewart Using Screen Readers on Windows ultimately result in a window receiving a very specific type of message from the OS, similar how a window receives for example a key down, or a mouse move, or a window resize.

I don't know all the details, but I believe a COM protocol based connection is then established between the Screen Reader and the window, and through this connection accessibility information travels.

Electron, through its use of Chromium, when it sees such a specific message type, decides to enable a flag that ultimately leads to data from the renderer process being sent over to the main process for accessibility purposes. We simply react when Electron lets us know it has entered this mode.

TL;DR: there might be software on your machine that is generating events going to windows that look very similar to the events that a Screen Reader would generate. Usually, UI automation software would use the same mechanisms as a Screen Reader. I'm not sure if it's useful or not, but if we'd get to know what software tricks Electron into entering accessibility mode, perhaps we can communicate that back to the Electron folks and they maybe could work around it.

@ChrisMBarr
Copy link

ChrisMBarr commented Aug 3, 2017 •
edited

The same thing is happening to me. The strange part is that it's intermittent. VSCode doesn't always launch with this green badge, but just sometimes.

This morning I got to my desk and opened VSCode and the badge was there: (note the time)
image

I saw it and search online, and found this issue. As I was typing this I decided to close and re-launch VSCode - and now the badge is gone (note the time again)!

image

The only thing I did while it was open is install a new extension.

I have no idea what software on my machine is thought to behave like a screen reader. The only software I have that does anything with an input device is "Logitech Options" for my MX Master mouse.

@anthony-gregg
Copy link

anthony-gregg commented Aug 3, 2017 •
edited

I have an even better variation of this. I opened VS Code this morning and also had the "Screen Reader Detected" green badge and it also was missing the Line Number and Character location. I closed VS Code and reopened it and now look at it:

image 22

I have not seen a scenario where both have been displayed based on the above statements. I also have no idea what software I have that is acting as a Screen Reader. I do have One Note, but that cannot be the case I would believe.

Update:
I just moved my cursor in VS Code and the Line Number and Character Location indicator disappeared. See below:

image 23

Now it looks the same as everyone elses.

@alexdima
Copy link
Member Author

alexdima commented Aug 8, 2017

@ChrisMBarr @anthony-gregg I'm sorry about you running into these false positive cases. Please change the setting editor.accessibilitySupport from "auto" to "off". We need to continue to ship with "auto" for the users that are forced to use a Screen Reader.

When the setting is "auto", we react to Electron telling us a Screen Reader is attached and then we proceed to do some tweaks: e.g. disable word wrapping, as wrapping points cannot be communicated correctly to Screen Readers (w3c spec limitation) and visually impaired users would hear "New Line" at the location of a wrapping point, which is incorrect. Another example is our removal of the Ln/Col indicator which would produce accessibility events that would throw off / confuse / spam NVDA.

In any case, it is probably a good idea to find out what software on your machine causes this, as, e.g. from my experience, when Electron/Chromium enters accessibility mode, VS Code will run a lot slower for you. e.g. electron/electron#7208 . It is also possible that Chrome on your machine will be running a lot slower than for other users. In Chrome, you can visit chrome://accessibility/ to find out if Chrome has entered this mode on your machine.

@anthony-gregg
Copy link

anthony-gregg commented Aug 8, 2017 via email

@ChrisMBarr
Copy link

So here's something else. I was working on one project this morning and no screen reader badge appeared. Without closing that project, I opened up another one and that one does have the screen reader banner at the same time!

image

So, I now have an instance of VSCode in each mode. Neat!

@anthony-gregg
Copy link

anthony-gregg commented Aug 10, 2017 via email

@ChrisMBarr
Copy link

@anthony-gregg I haven't changed the defaults, so yes I suppose so.

I think I'm going to turn this off now since it's not something I need.

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@alexdima alexdima

Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues bug Issue identified by VS Code Team member as probable bug important Issue identified as high-priority info-needed Issue requires more information from poster verification-needed Verification of issue is requested verified Verification succeeded
Projects
None yet
Milestone
May 2017
Development

No branches or pull requests
6 participants
@ChrisMBarr @bpasero @Tyriar @alexdima @Bill-Stewart @anthony-gregg