[GUOZIJAN]

Fixes #5655

TL;DR

• Screen readers announced the Installation options tabs as Avalonia.Controls.Border and the Operation history tabs as Avalonia.Controls.Grid / OperationHistoryLogView: the tab headers are custom stacks (icon + text blocks) with no automation name, so UIA fell back to the template control class names.
• Sets AutomationProperties.Name on each of the five Installation options TabItems and the two Operation history TabItems, bound to the same labels that are already visible on screen (TabGeneralLine1 / TabLocationLine1 / TabCLILine1 / TabCloseAppsLine1 / TabPrePostLine1, and {t:Translate History} / {t:Translate Log}), so the announced name always matches what sighted users see, including localized values.

Verification

• dotnet build src/UniGetUI.Avalonia/UniGetUI.Avalonia.csproj -c Release succeeds (0 errors) on Windows.
• Screen-reader behavior itself can't be exercised automatically; the names are bound to the same localized strings the headers display, so they will follow any future label changes.

[Keyang556 (keyang556)]

Thanks for the quick fix!

I noticed that the five Installation options tabs currently use only the first line of their visible headers for AutomationProperties.Name (for example, TabGeneralLine1).

While this fixes the original issue of screen readers announcing internal Avalonia control class names, the second line sometimes contains important information rather than just a description.

For example:

• General / Version
• Architecture / Location and Scope
• Command-line / Arguments
• Close apps / before installing
• Pre-install / Post-install

In particular, announcing only "Pre-install" could be misleading, since the tab also contains post-install options.

Would it be possible to combine both existing localized strings into the accessible name of each tab?

I noticed that other UniGetUI controls, such as SettingsPageButton, use AutomationProperties.Name for the primary label and AutomationProperties.HelpText for additional descriptions. However, in this case, both lines seem to form the actual tab title, so combining them into one accessible name would probably be more appropriate.

This should not require any new translations or changes to the existing keyboard navigation.

Thanks again for addressing this so quickly!

[GUOZIJAN]

Done in the follow-up commit: each tab's AutomationProperties.Name now combines both localized header lines (TabGeneralName = "General — Version", TabPrePostName = "Pre-install — Post-install", etc.), so the announced name matches the full visible title. The XAML binds to new combined properties on InstallOptionsViewModel built from the same CoreTools.Translate calls, so no new translations are needed and the names stay in sync with the visible headers.