AccessibleName runtime announcement behavior in VB.NET Windows Forms

Direct answer

Assigning AccessibleName at runtime updates the string returned by the control's MSAA IAccessible.accName implementation immediately, in the same process. The control does not need to recreate its accessibility object for the value itself. What is not automatic is the announcement: Windows Forms does not guarantee that assistive technology receives a name-change notification or reads the new name without a focus change or tree navigation. To make the change visible to accessibility clients promptly, raise a name-change event after the assignment.

Confirmed facts versus likely explanation

Item	Status
AccessibleName property value updates immediately	Confirmed for in-process MSAA reads
Accessible object recreation required	Not required for the value change
Screen reader announces without notification	Not guaranteed; varies by reader and runtime
.NET Framework versus .NET 6+ behavior identical	Not established; treat as version-dependent

Steps for this case

1. Make the assignment on the UI thread:

Button1.AccessibleName = "Submit order"

1. Notify MSAA clients immediately after the assignment, passing the control's object identifier and -1 for childID when the change applies to the control itself:

Me.AccessibilityNotifyClients(AccessibleEvents.NameChange, Button1.Handle.ToInt32(), -1)

1. For UI Automation consumers, confirm that the equivalent Name property-changed notification is supported in your target runtime; do not assume it is raised automatically.
2. Verify without moving focus: inspect the control's Name with Inspect.exe or AccScope before and after the assignment, and capture events with AccEvent or UIA Verify.
3. Test announcement with Narrator and one third-party screen reader while focus remains on another control.

Version assumptions and uncertainty

.NET Framework Windows Forms is primarily MSAA-centric, so AccessibilityNotifyClients is the established notification path. .NET 6 and later Windows Forms expand UI Automation support, but exact version-specific differences in name-change announcement are not established in the available research. Screen reader behavior also depends on whether the reader polls the accessibility tree or relies on events, so results may differ between Narrator, NVDA, and JAWS.

Missing diagnostic detail

Which screen reader and .NET runtime are you targeting? That detail changes which verification steps and notification paths are most relevant.

Note: AccessibleName supplements, but does not replace, visible labels, focus order, keyboard access, or an appropriate AccessibleRole.

Conservative draft: verify announcement behavior with your target screen reader and .NET runtime before relying on it in production.