Widgets are unable to be saved if they contain instances of other widgets that override their own Accessible Defaults. See the repro steps for more details.
Upon trying to save, the user is met with an error message that reads “The asset ‘AssetPath’ (AssetName.uasset) failed to save.” Additionally, the following error is displayed in the output:
> Can’t save ‘Path/To/WBP_Asset.uasset’: Illegal reference to private object: ‘SlateAccessibleWidgetData /Path/To/Child/WBP_ChildAsset.Default__WBP_ChildAsset_C:SlateAccessibleWidgetData_0’ referenced by ‘Default__WBP_ChildAsset_C’ (at ‘/Path/To/Child/WBP_ChildAsset’) in its ‘AccessibleWidgetData’ property.
Note that I was able to prevent this issue from happening by making the following modification in Widget.h:
/** A custom set of accessibility rules for this widget. If null, default rules for the widget are used. */
UPROPERTY(Instanced, meta = (AllowPrivateAccess = true))
TObjectPtr<USlateAccessibleWidgetData> AccessibleWidgetData;
Is this a valid fix, or could this introduce other potential issues?
Within WidgetB, set the property Override Accessible Defaults to true
Save and compile WidgetB
Within WidgetA, select the instance of WidgetB and ensure that the property Override Accessible Defaults is set to true (click on the revert arrow if needed)
Thanks for the detailed report and repro steps. I can confirm that this issue reproduces consistently on my end as well. I tested across UE 5.5, 5.6, 5.7 and a recent source build from Main (CL 48526824), and the behavior persists in all versions.
I’ll continue looking into this behavior and will follow up soon.
Regarding your temporary workaround you suggested:
UPROPERTY(Instanced, meta = (AllowPrivateAccess = true))
TObjectPtr<USlateAccessibleWidgetData> AccessibleWidgetData;
I’ve tested this locally in 5.6 and it triggers various flag asserts when the Override Accesible Defaults property is modified (either turned on/off constantly) and then trying to save the container widget (WidgetB in your case).
[2025.12.04-00.23.43:675][281]LogWindows: Error: Assertion failed: !(NewFlags & (RF_MarkAsNative | RF_MarkAsRootSet | RF_MirroredGarbage)) [File:D:\P4-5.6\Engine\Source\Runtime\CoreUObject\Public\UObject\UObjectBaseUtility.h] [Line: 68] I would suggest to avoid having nested widget blueprints when the child widget has Override Accessible Defaults is set to true.
Please let me know if you need anything else on this case.
Hi Francisco! Thank you for testing out the attempted fix, too bad it’s not the silver bullet we need
> I would suggest to avoid having nested widget blueprints when the child widget has Override Accessible Defaults is set to true.
This doesn’t seem feasible nor realistic. If for example we have a button widget nestled somewhere inside the hierarchy of a menu widget, how are we supposed to go about making the button accessible for the screen reader? Is there a different workaround we could use, or are we pretty much stuck here until a fix is sorted out?
Sorry for the confusion earlier. I should clarify what I meant. The issue is not with nested widgets in general but specifically when the child widget has “Override Accessible Defaults” enabled in its class defaults.
After doing further testing, I found a more viable workaround that avoids the save failure:
Leave “Override Accesible Defaults” off on the child widget asset (WidgetB in your repro steps).
Add an instance of WidgetB to WidgetA.
Enable “Override Accessible Defaults” on the instance inside the parent’s widget tree and set up the accessibility options there.
In this setup, the accessibility data is created as part of the parent widget’s object graph instead of the child’s CDO. This approach prevents save failure in UE 5.5, 5.6, and later versions.
Please let me know if this workaround is acceptable for your use case.
Hey Francisco, thanks for the workaround. It applies for straightforward cases, but we also need to account for dynamically runtime-instanced widgets, list views, tooltip widgets, etc. For example, we have the following use case:
A widget contains a CommonTabListWidget that dynamically populates a list of buttons
That same widget also contains a few concrete instances of those buttons
We want the buttons to have their Accessible Behavior set to Tool Tip
At best, I guess I could introduce some custom changes to modify the underlying AccessibleWidgetData properties at runtime, such that when the widget is created we then could specify our desired behavior in blueprint graph? It feels like a bit of an anti-pattern but it could maybe satisfy our needs for the time being.
You’re right, for the cases you mentioned, setting the accessibility values at runtime is actually a valid workaround in this situation. Since the save failure only occurs when the child widget’s class defaults contain overridden accessibility data, applying those settings per instance avoids the problem entirely.
You can base your runtime setup on what the engine does inside UWidget::SynchronizeProperties() in Widget.cpp. At the end of that function, the accessibility data is applied to the underlying Slate widget like this:
if (AccessibleWidgetData)
{
TSharedPtr<SWidget> AccessibleWidget = GetAccessibleWidget();
if (AccessibleWidget.IsValid())
{
AccessibleWidget->SetAccessibleBehavior((EAccessibleBehavior)AccessibleWidgetData->AccessibleBehavior, AccessibleWidgetData->CreateAccessibleTextAttribute(), EAccessibleType::Main);
AccessibleWidget->SetAccessibleBehavior((EAccessibleBehavior)AccessibleWidgetData->AccessibleSummaryBehavior, AccessibleWidgetData->CreateAccessibleSummaryTextAttribute(), EAccessibleType::Summary);
AccessibleWidget->SetCanChildrenBeAccessible(AccessibleWidgetData->bCanChildrenBeAccessible);
}
}
You can recreate this logic after spawning your dynamic widgets so each instance receives its own accessibility configuration. This seems like a valid approach while the engine fix is pending.
Please let me know if you need anything else regarding this case.
