Powertoys: Keyboard Trap Accessibility issue in Settings page of FancyZones, PT Run and ColorPicker

Created on 22 Aug 2020 · 8Comments · Source: microsoft/PowerToys

ℹ Computer information

PowerToys version:
PowerToy Utility:
Running PowerToys as Admin:
Windows build number: [run "winver"]

📝 Provide detailed reproduction steps (if any)

There is a keyboard trap in the Settings page.

The PowerToys settings page affected by this-

FancyZones
PT Run
Colorpicker

✔️ Expected result

_What is the expected result of the above steps?_

We should be able to access all the elements of the settings page using the keyboard.

We should allow the user to hold tab and this should take the focus to the next element. There should be some help text which informs the user of this.

❌ Actual result

_What is the actual result of the above steps?_

Once we enter this window, since it captures our keystrokes, there is no way we can set focus on any other item using only the keyboard (by pressing tab).

📷 Screenshots

_Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form_

Accessibility [E+D] Area-Accessibility Issue-Bug Priority-0 Product-Settings Resolution-Fix-Committed

Source

alekhyareddy28

All 8 comments

@ryanbodrug-microsoft, @saahmedm, @crutkas Other than this issue and the other external winui dependent issues (for which we have tracking issues), all the settings page issues (excluding KBM settings page which has been included with the rest of KBM issues) that were highlighted by accessibility insights and the screen reader have been fixed.

I have PRs open for the each of the settings pages which fix the rest of the issues. This issue is for the custom HotKeySettingsControl.xaml which is used by each of PT Run, FZ and ColorPicker settings pages as we need the help of the mouse/touchpad to get out of the control where we set the hotkey. I could either keep these three issues (#5733, #5734, #5739) open till this current tab trap issue is fixed or add the fix committed label to those issues as and when their PRs get merged into master and have this as the tracking issue for tab trap. Please let me know and I shall proceed that way.

I think we might want to reach out to the Accessibility team regarding this. Whether it would be best to have a time limit like in the KBM windows and if so how much would be ideal. Also, is there something else that must be kept in mind while doing so.

I've added this to the 2008 milestone as it is related to the rest of the settings issues. Please move it to the correct milestone if it is to be done later.
Thank you.

alekhyareddy28 on 22 Aug 2020

In terms of solving the keyboard trap issue I think we could either go with a time limit as suggested above (this has the downside that you are pressuring the user to finish typing within a fixed time, or they have to wait for too long to proceed). Since the hold Enter/Esc does not make sense here since there are no buttons to be pressed (as in the case of KBM's dialog), we could set it up such that "hold Tab" can be used to move to the next control, and similarly "hold Shift+Tab" to move to the previous control.

arjunbalgovind on 22 Aug 2020

Sorry if I wasn't clear but that is what I meant. Like the user might have to hold down tab for a while. I was just wondering if there is a standard for the amount of time that a key has to be pressed and what would be ideal.

alekhyareddy28 on 22 Aug 2020

👍1

For the KBM, We had discussed this with the C+AI team for the solution. This is why we have the press and hold escape text. Maybe we need more narrator text to give a better hint.

For tab order, I think we should refactor the control we have from KBM and make it into a more standard control. I don't see how we get out of a tab order problem otherwise.

I think we should file maybe a dedicated issue to call this out and list the pages affected.