[Terminal> Rename Window]: Keyboard users are not able to access 'Window 1' pop-up when they open it using defined shortcut key. #12021
Labels
A11yCO
Accessibility tracking
A11ySev1
Accessibility tracking
A11yWCAG
Accessibility tracking
Area-Accessibility
Issues related to accessibility
HCL-E+D
Accessibility tracking
HCL-WindowsTerminal
Accessibility tracking
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Priority-1
A description (P1)
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Available
It's available in an Insiders build or a release
Tracking-External
This bug isn't resolved, but it's following an external workitem.
WindowsTerminal_Win32
zAskModeBug
Milestone
Comments
|
We're already tracking this in #11322, which is blocked on the upstream microsoft/microsoft-ui-xaml#1607 - there's no way for us to reliably focus a |
|
@v-rpundir Just want to confirm. Since this is blocked by microsoft/microsoft-ui-xaml#1607, you're marking this as a "tracking external" bug, correct? |
|
Yes @carlos-zamora, we are tracking this external for now. |
This was referenced Jan 28, 2022
This was referenced Mar 31, 2022
ghost
pushed a commit
that referenced
this issue
Mar 31, 2022
Does what it says on the tin. This is maximal BODGE. `TeachingTip` doesn't provide an `Opened` event. (microsoft/microsoft-ui-xaml#1607). But we want to focus the renamer text box when it's opened. We can't do that immediately, the TextBox technically isn't in the visual tree yet. We have to wait for it to get added some time after we call IsOpen. How do we do that reliably? Usually, for this kind of thing, we'd just use a one-off LayoutUpdated event, as a notification that the TextBox was added to the tree. HOWEVER: * The _first_ time this is fired, when the box is _first_ opened, yeeting focus doesn't work on the first LayoutUpdated. It does work on the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated events, and focus on the second. * On subsequent opens: We only ever get a single LayoutUpdated. Period. But, you can successfully focus it on that LayoutUpdated. So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If we've had at least 2, then we can focus the text box. We're also not using a ContentDialog for this, because in Xaml Islands a text box in a ContentDialog won't receive _any_ keypresses. Fun! ## References * microsoft/microsoft-ui-xaml#1607 * microsoft/microsoft-ui-xaml#6910 * microsoft/microsoft-ui-xaml#3257 * #9662 ## PR Checklist * [x] Will close out #12021, but that's an a11y bug that needs secondary validation * [x] Closes #11322 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed Tested manually
DHowett
pushed a commit
that referenced
this issue
Mar 31, 2022
Does what it says on the tin. This is maximal BODGE. `TeachingTip` doesn't provide an `Opened` event. (microsoft/microsoft-ui-xaml#1607). But we want to focus the renamer text box when it's opened. We can't do that immediately, the TextBox technically isn't in the visual tree yet. We have to wait for it to get added some time after we call IsOpen. How do we do that reliably? Usually, for this kind of thing, we'd just use a one-off LayoutUpdated event, as a notification that the TextBox was added to the tree. HOWEVER: * The _first_ time this is fired, when the box is _first_ opened, yeeting focus doesn't work on the first LayoutUpdated. It does work on the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated events, and focus on the second. * On subsequent opens: We only ever get a single LayoutUpdated. Period. But, you can successfully focus it on that LayoutUpdated. So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If we've had at least 2, then we can focus the text box. We're also not using a ContentDialog for this, because in Xaml Islands a text box in a ContentDialog won't receive _any_ keypresses. Fun! ## References * microsoft/microsoft-ui-xaml#1607 * microsoft/microsoft-ui-xaml#6910 * microsoft/microsoft-ui-xaml#3257 * #9662 ## PR Checklist * [x] Will close out #12021, but that's an a11y bug that needs secondary validation * [x] Closes #11322 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed Tested manually (cherry picked from commit b57fe85) Service-Card-Id: 79978834 Service-Version: 1.13
DHowett
pushed a commit
that referenced
this issue
Mar 31, 2022
Does what it says on the tin. This is maximal BODGE. `TeachingTip` doesn't provide an `Opened` event. (microsoft/microsoft-ui-xaml#1607). But we want to focus the renamer text box when it's opened. We can't do that immediately, the TextBox technically isn't in the visual tree yet. We have to wait for it to get added some time after we call IsOpen. How do we do that reliably? Usually, for this kind of thing, we'd just use a one-off LayoutUpdated event, as a notification that the TextBox was added to the tree. HOWEVER: * The _first_ time this is fired, when the box is _first_ opened, yeeting focus doesn't work on the first LayoutUpdated. It does work on the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated events, and focus on the second. * On subsequent opens: We only ever get a single LayoutUpdated. Period. But, you can successfully focus it on that LayoutUpdated. So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If we've had at least 2, then we can focus the text box. We're also not using a ContentDialog for this, because in Xaml Islands a text box in a ContentDialog won't receive _any_ keypresses. Fun! ## References * microsoft/microsoft-ui-xaml#1607 * microsoft/microsoft-ui-xaml#6910 * microsoft/microsoft-ui-xaml#3257 * #9662 ## PR Checklist * [x] Will close out #12021, but that's an a11y bug that needs secondary validation * [x] Closes #11322 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed Tested manually (cherry picked from commit b57fe85) Service-Card-Id: 79978833 Service-Version: 1.12
|
@v-rpundir This should now be fixed in https://github.com/microsoft/terminal/releases/tag/v1.13.10983.0 Can you confirm and close the bug please? |
|
Closing as fixed now on Windows Terminal Preview Version: 1.13.10984.0 |
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Windows Terminal version
1.12.3472.0
Windows build number
10.0.22504.1010
Other Software
Test Environment:
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator
Tool: Accessibility Insights for Windows Version 1.1.1741.1
Steps to reproduce
Repro Steps:
User Experience:
As pop-up control are not accessible with Keyboard as a result, they will not able rename Window name.
Guideline Reference:
https://www.w3.org/WAI/WCAG21/Understanding/focus-order
Attachments:
Keyboard user is not able to access Window 1 Pop-up. (2).zip
Expected Behavior
Keyboard users should directly jump to 'Window 1' edit field when user open 'Window 1' pop-up using defined shortcut key.
Actual Behavior
Keyboard users are not able to access 'Window 1' pop-up when they open it using defined shortcut key.
Note Issue: Screen Reader users are not able to access 'Window 1' pop-up when they open it using defined shortcut key. Screen Reader is announcing 'Press F6 key to access...' but nothing happened on pressing F6.
The text was updated successfully, but these errors were encountered: