1986839 - If On Screen Keyboard is running, Gecko accessibility isn't enabled when Voice Access or Narrator is activated without switching windows

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

STR (for Voice Access):

1. If Firefox is running, close it.
2. Windows Settings -> Accessibility -> Keyboard, turn on On-screen keyboard.
3. Windows Settings -> Accessibility -> Speech, turn on Voice access.
4. Ensure Voice Access is asleep, not active.
5. Start Firefox.
6. Say: Voice Access wake up.
7. Say: show numbers.
   • Expected: Numbers should be displayed near controls in Firefox.
   • Actual: Numbers appear, but not for Firefox controls.

STR (for Narrator):

1. If Firefox is running, close it.
2. Windows Settings -> Accessibility -> Keyboard, turn on On-screen keyboard.
3. Start Firefox.
4. Press Windows+control+enter to start Narrator. Do not switch windows.
5. Try to navigate Firefox with the tab key.
   • Expected: Narrator should announce controls as you navigate.
   • Actual: No controls are announced.

Switching away from Firefox and back again fixes this.

This is particularly problematic for Voice Access because users who cannot use a keyboard might very well use both Voice Access and On-screen Keyboard. In fact, this was discovered during a Fable user testing session with a user who does precisely this. When this happens, Voice Access cannot interact with Firefox at all, and the user won't understand why.

This happens because we block instantiation of the accessibility engine by On-screen Keyboard. It doesn't really need accessibility, but was causing stability problems; see bug 1424505. However, because UIA client detection can be slow and some badly behaved clients might query us many times, we cache the result and we don't fetch it again until the user switches windows.

We should find a way to work around this for On-screen Keyboard. For example, perhaps we can have a 5 second timeout or similar if only On-screen Keyboard was detected. However, if other clients were blocked, we should still only clear the cache when the user switches windows, as those clients might be badly behaved and hammer us with queries.

Comment 1

[James Teh [:Jamie]]

I discussed this with Morgan. On-screen Keyboard was originally blocked because it was causing stability problems. However, the crash in question was related to COM, which was almost certainly due to our very strange use of COM prior to Cache the World. So, the simplest solution might just be to unblock On-screen Keyboard.