When we navigate to "Auto Size" dropdown using the up/down arrow keys, it is getting auto selected without hitting ENTER key:A11y_ A11y_.NET CoreWinforms_On Focus.

[AnKushSingh05]

.NET version

dotnet-sdk-9.0.100-preview.5.24258.1

Did it work in .NET Framework?

.NET Framework and the InProc designer work the same as .NET+OOP designer

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No response

Issue description

GitHub Tags:

#A11yMAS; #A11yTCS; #A11ySev2; #BM_.NET Core[Winforms]_Win32_May2024; #.NETCore; #WCAG3.2.1; #DesktopApp; #Win11;#keyboard;#On Focus;#Closed;

Environment Details:

App name: .NET Core Winforms
Window Version: Win 11
OS Build: 22621.3085
Screen readers: Narrator, NVDA 2023.3.3

Repro Steps:

1. Launch the "Accessibility core app".
2. Main Form screen would appear.
3. TAB to "Remaining_Controls_Testing the controls under Printing Tab" and hit ENTER key.
4. "Remaining_Controls" popup will appear.
5. Tab till Auto size dropdown under layout section.
6. Observe that when we navigate to "File type" dropdown using the up/down arrow keys, it is getting auto selected without hitting ENTER key

Actual Result:

When we navigate to "Auto Size" dropdown using the up/down arrow keys, it is getting auto selected without hitting ENTER key

Expected Results:

When we navigate to "Auto Size" dropdown using the up/down arrow keys it should be selected after hitting ENTER key.

User Impact:

User who relies on keyboard will face difficulty as they might select the control which they did not intent.

Attachment

Bug_12031_On.Focus.mp4

[AnKushSingh05]

Primary bug: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2164329

[Zheng-Li01]

There have the same behaviors between .NET Framework and .NET on both Designer and Run time as below screenshot.
The user can directly select the value of Auto Size by using up/down arrow keys dropdown panel, the issue cannot reproduce other properties.
.NET Framework:

.NET:

[merriemcgaw]

We will need to fix this in .NET 10 since we don't have time to make it in .NET 9. We should work with the Accessibility team to get this added to an accessibility plan allowing us to fix it in .NET 10. I don't think there's enough benefit to warrant servicing .NET 9 unless we get customer requests.

Need to ask about GitHub tags in Office Hours today.

[merriemcgaw]

@Zheng-Li01 can you confirm this is the same behavior across all of the "combo boxes" in the PropertyGrid?

I will be filing AccessibilityPlan for the .NET WinForms PropertyGrid and a second one for VS. The .NET one will need to be addressed in .NET 10 and cover at least the ComboBoxe types of TypeEditors that we own. The VS plan will be separate.

[Zheng-Li01]

@merriemcgaw, go throughed all of the "combo boxes" in the PropertyGrid for Form, Lable, Button, ToolStrip, GroupBox etc. controls. the issue only can reproduce on Auto Size property, not reproduce on other properties.

[merriemcgaw]

@Zheng-Li01 can you see if it repros on a custom PropertyGrid with a bool type of property in it?

[Zheng-Li01]

@Zheng-Li01 can you see if it repros on a custom PropertyGrid with a bool type of property in it?

Not reproduce on a custom PropertyGrid with a bool type of property in it as below screenshot.

[merriemcgaw]

@LeafShi1 can you please go ahead and fix this issue? We will create another issue to track improving the keyboard usability of the PropertyGrid as a feature for .NET 10.

[LeafShi1]

The following properties also have this issue:

1. The AutoSize property of the TextBox or other control
   • The Size property will be changed once you select the new value in the drop down
2. The Multiline property of the TextBox
   • The Size property will be changed once you select the new value in the drop down
3. The Alignment property of the TabControl
   • The ItemSize property will be changed once you select the new value in the drop down
4. The Checked and CheckState property of the CheckBox
   • Checked and CheckState properties are interdependent
5. The RowHeadersWidthSizeMode and ColumnHeadersHeightSizeMode of the DataGridView

• The RowHeadersWidth property will be changed once you select the new value in the drop down of the RowHeadersWidthSizeMode
• The ColumnHeadersHeight property will be changed once you select the new value in the drop down of the ColumnHeadersHeightSizeMode

6. The Frozen of the DataGridViewColumn
   • No other property change when you select the new value in the drop down

[Tanya-Solyanik]

@Zheng-Li01 @LeafShi1 @merriemcgaw I'm not sure if the way described in the bug is the est way to navigate type editor with the keyboard.
Here is what i'm doing
0. focus is on a label on a form in the designer

1. ALt+ENter
2. user up and down arrows to navigate to autosize property name
3. tab to the edit field on the right hand side
4. tab to the drop-down button
5. ENTER - drop down opens
6. press an up or down arrow to change the value.
   Result: value is changed, drop down is closed, size property is updated in the property grid and on Ctrl+S .designer.cs file is updated correctly. The confusing part is that other properties require an explicit "ENTER" inside the drop down.

I think that when navigating with the keyboard, a more convenient sequence is,
2. user up and down arrows to navigate to autosize property name
3. tab to the edit field on the right hand side
4. press an up or down arrow to change the value.
This seems to me a convenient flow because I don't have to press extra buttons to make a selection. This sequence works for other properties as well, our fix should not break it.

I would like to understand the rule this UI is violating better. I see

When any user interface component receives focus, it does not initiate a change of context.

here - https://www.w3.org/TR/WCAG21/#predictable

But ours is not the case of getting focus, the edit box received focus on TAB(step 3), on arrow we changed the value.

[LeafShi1]

@Zheng-Li01 @LeafShi1 @merriemcgaw I'm not sure if the way described in the bug is the est way to navigate type editor with the keyboard. Here is what i'm doing 0. focus is on a label on a form in the designer

After the change, we can still press the up and down keys on the edit box to change the value.
It's just that before the change, the edit box loses focus after pressing the up and down keys, but it will not after the change.

The whole operation process is some linkage behavior, and it does not cause context change.

Before Changes:

After Changes:

[Tanya-Solyanik]

@merriemcgaw - do you agree with #A11ySev2; assessment? Keyboard user does not have to open the drop down at all to perform these changes.

[merriemcgaw]

@Tanya-Solyanik yeah, I do. This is an example of the type of thing the SMEs were worried about us needing to fix. The value shouldn't be committed until the user takes action to hit enter or leave the field, IMO.

[AnKushSingh05]

@LeafShi1 Could you please provide the environment to verify the issue?. Thanks!

[Syareel-Sukeri]

The issue has been verified in the latest .NET 10 SDK build: .NET 10.0.100-alpha.1.24556.12 and is now resolved. The value is no longer being auto selected, and focus is maintained when using the up/down arrow keys, both when opening the dropdown or without doing so.

DropDownFix.mp4

[AnKushSingh05]

The issue has been verified in the latest .NET 10 SDK build: .NET 10.0.100-alpha.1.24556.12 and is now resolved. The value is no longer being auto selected, and focus is maintained when using the up/down arrow keys, both when opening the dropdown or without doing so.

DropDownFix.mp4

@Syareel-Sukeri Can you please give the environment link

[Syareel-Sukeri]

@AnKushSingh05 You can access the Accessibility-Core-App and .NET 10 for testing from this link: https://microsoft-my.sharepoint.com/:f:/p/v-smdsukeri/EmvP63iKbZBOq0Mwe4LY8uEBBfIjniIzd3ma660aVSp17w?e=Ahd0vc. Let me know if you cannot access it.

[AnKushSingh05]

Verified the issue in .NET 10 SDK build: .NET 10.0.100-alpha.1.24556.12
Issue is fixed. Hence closing the bug
https://github.com/user-attachments/assets/2ab02f7a-2168-46d8-864a-50bc0645aa9b