ControlAccessibleObject should bridge GetFocused() to UIA IRawElementProviderFragmentRoot.GetFocus()

[trypsynth]

Summary

When building a custom WinForms control with child accessible objects (e.g. a grid where each cell is a CellAccessibleObject : AccessibleObject), overriding GetFocused() on a ControlAccessibleObject subclass correctly exposes the focused child to MSAA clients. However, UIA clients, including NVDA, never see it.

Root cause

IRawElementProviderFragmentRoot.GetFocus() is implemented in AccessibleObject by calling an internal virtual method that returns null by default. ControlAccessibleObject does not override it, so UIA always reports the control itself as focused, regardless of what GetFocused() returns. DataGridView works correctly because it overrides GetFocus() from inside the WinForms assembly:

internal override IRawElementProviderFragment.Interface? GetFocus() => GetFocused();

External code has no equivalent escape hatch. GetFocused() is public and functional, but the UIA path never reaches it. To repro:

1. Create a custom control with a ControlAccessibleObject subclass
2. Override GetFocused() to return a child AccessibleObject
3. Focus the control with NVDA running
4. Press NVDA+Tab to read the focused element

Actual result: NVDA reports the control, not the child cell.

Expected result: NVDA reports the focused child (the cell accessible object returned by GetFocused())

Proposed fix

Either make GetFocus() protected virtual so external subclasses can override it, or have ControlAccessibleObject implement it as return GetFocused() as IRawElementProviderFragment.Interface; by default, matching what DataGridView already does internally.

[LeafShi1]

The GetFocused() bridge does not affect whether a UIA element has children or whether child elements are discoverable via navigation.

In UIA, whether a specific child element can be read by assistive technologies depends on whether that element exists in the fragment tree and can be reached through fragment navigation. Overriding GetFocused() alone does not create new nodes or change the fragment hierarchy.

Because of this, bridging GetFocused() to UIA GetFocus() would not make previously undiscoverable child elements navigable or readable by UIA clients.

If there is a concrete project or repro where the lack of this bridge causes an observable accessibility gap (with an existing fragment tree), please share it so we can better understand the scenario.

[trypsynth]

@LeafShi1 Thanks for the clarification. To address the fragment tree question directly: the child AccessibleObject instances are reachable via MSAA (GetChild/GetChildCount/GetFocused), but they are not in the UIA fragment tree, and that's exactly the problem we can't solve from outside the assembly. UIA fragment navigation goes through IRawElementProviderFragment.Navigate(), which is backed by the internal virtual FragmentNavigate(). Since external subclasses of ControlAccessibleObject can't override FragmentNavigate(), there's no way to make child accessible objects appear in the UIA tree from user code, regardless of what GetFocused() returns. So the issue is actually two missing pieces, not one:

1. FragmentNavigate() needs to be overridable (or default to delegating to the public Navigate()) so external subclasses can build a UIA fragment tree with virtual children.
2. Once the fragment tree exists, GetFocus() needs to be bridged so that focus on a child element is reported correctly to UIA clients.

DataGridView works because it can override both internally. External controls with virtual children (grids, tree views, list views drawn owner-side) have no equivalent path.

The observable gap: NVDA's "report focus" command (NVDA+Tab) always reports the control itself, not the focused child, even though the same child is announced correctly on navigation via the MSAA EVENT_OBJECT_FOCUS path. A minimal repro would be a custom control with GetChildCount/GetChild/GetFocused overridden — NVDA+Tab will consistently read the parent control name instead of the focused child.

The repository I discovered this in is https://github.com/trypsynth/elem it's pretty small and self-contained and shows the problem with NVDA on the first tab, but if you need a more minimal example please let me know.

[LeafShi1]

Focus bridging is effective only when the focused element already exists in the UIA fragment tree.
External WinForms controls cannot construct or extend the UIA tree. As a result, for virtual child elements, focus bridging alone has no observable effect.
Conversely, when a child element is already part of the UIA tree, NVDA can correctly announce focus changes even without MSAA-based bridging.
This leads to the core question: whether FragmentNavigate() should be exposed as an extensibility point so external controls could customize the UIA fragment tree. Doing so would require introducing new public APIs and lifecycle contracts, which would constitute a fundamental design change.
For these reasons, we consider the current behavior to be by design.
@KlausLoeffelmann @merriemcgaw what are your thoughts?

[trypsynth]

Thanks for the detailed follow-up. Understood on focus bridging requiring the fragment tree to exist first and focus bridging alone having no observable effect.

On the "by design" question: the ask isn't necessarily to expose FragmentNavigate() as a new public extension point. A narrower fix would be to have ControlAccessibleObject's base implementation of FragmentNavigate() delegate to the existing public Navigate() method, the same pattern DataGridView already uses internally. That would require no new API surface or lifecycle contracts; it would just make Navigate() meaningful for UIA clients, which is presumably its intent.

The current situation means any custom owner-drawn control with virtual children (grids, calendars, color pickers, etc.) has no accessible path to UIA tree participation short of switching to real child Control instances, which isn't viable for virtual/large item sets. That seems like a gap worth closing even if a full FragmentNavigate() extensibility story isn't on the roadmap, understandably I'd say.

@KlausLoeffelmann @merriemcgaw @LeafShi1 thoughts? Am I missing something obvious due to not knowing this codebase well at all?

[LeafShi1]

FragmentNavigate delegates to the existing public Navigate() method, it merely provides an additional extension point for built-in controls that already support UIA. It is effective only for "controls that support UIA providers" (specifically, built-in controls where SupportsUiaProviders == true—such as ListBox, DataGridView, etc.), for purely custom Control implementations, it does not cause the UIA tree to utilize a custom Navigate implementation.