[Accessibility] Focus cue not shown on startup for multiple WinForms controls when multiple focusable controls exist

[Olina-Zhang]

.NET version

.NET 11 SDK with 11.0.100-preview.4.26208.110 build

Did it work in .NET Framework?

No

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

No

Issue description

In WinForms, several controls that receive input focus on startup do not display any visible focus indication when multiple focusable controls are present on the form.

This results in inconsistent and potentially confusing UX, as users cannot determine which control is currently focused.

Actual Result:
Only ComboBox (DropDownStyle = DropDownList): it has focus cue.

After added button:
The control(ComboBox) does not show any visible focus cue on startup
However:

• Pressing Tab once moves focus to the Button
• This indicates that the control actually had focus initially

Expected result:
A control that has input focus should provide a visible focus indication on startup, regardless of the presence of other focusable controls.

Steps to reproduce

1. Create a new WinForms .NET application
2. Add one of the following controls to the form:
   • ComboBox (DropDownStyle = DropDownList)
   • ListBox
   • CheckedListBox
   • ListView
   • TreeView
   • TabControl
   • TrackBar
     Ensure:
     • TabIndex = 0
3. Run the application
   → The control shows a focus cue
4. Add a Button to the form (default settings)
5. Run the application again to observe

[LeafShi1]

The behavior comes from the native Win32 trackbar and OS UI state, not from custom WinForms painting.

• TrackBar is a wrapper over the native TRACKBAR_CLASS and is not UserPaint, so the focus rectangle is drawn entirely by comctl32 and controlled by the window UI state (UISF_HIDEFOCUS, WM_CHANGEUISTATE/WM_UPDATEUISTATE).
• With only a TrackBar on the form, no UI‑cues logic runs on startup, the UI state stays at its default (focus cues visible), and the native trackbar draws its focus rectangle.
• Once there is a second focusable control like a Button, WinForms’ UI‑cues code runs (respecting the OS setting “hide focus cues until keyboard use”), sends WM_CHANGEUISTATE(UIS_SET | HIDEFOCUS | HIDEACCEL), and the OS updates UISF_HIDEFOCUS to “hidden”. The TrackBar still has keyboard focus, but because it only uses the focus rectangle as its visual cue, and that rectangle is now hidden by UI state, it appears unfocused. Other controls still show caret/selection/highlight, so they remain visually obvious.

Changing this in the framework would either

1. globally override the OS focus‑cue setting for all apps
2. require WinForms to re‑implement the trackbar’s painting and bypass the native behavior.

Both are high‑risk, breaking changes, so we do not plan to change the default WinForms behavior here. Apps that need focus cues to be always visible can opt in by clearing UISF_HIDEFOCUS themselves after the form is shown.

If we see customer feedback or accessibility requirements around this specific behavior, we’ll revisit the design.