iOS: VoiceOver cannot select or activate any control (accessibility tree appears empty)

[HenriApperloo]

Describe the bug

VoiceOver on iOS: accessibility tree appears empty, no element can be selected or activated

Summary

On iOS, VoiceOver cannot select or activate any control in an Avalonia application. Swiping produces only the "no element" tone; tapping a control does not place the VoiceOver cursor on it and nothing is announced. The app itself is not frozen — it is fully usable again the moment VoiceOver is turned off, and touch input works normally with VoiceOver disabled. This suggests the UIAccessibility bridge exposes no elements, so VoiceOver intercepts every touch and never finds anything to hand it to.

The same application code works correctly on macOS: VoiceOver announces controls, reads their AutomationProperties.Name, and tab navigation moves through the tree as expected.

Environment

Avalonia	12.1
.NET	10.0
Microsoft.iOS.Sdk	26.5.10284
Xcode	26.6
Device	iPhone 17 Pro (iPhone18,3)
iOS	26.6 (23G71)
Build configuration	Debug, deployed to physical device
macOS (working comparison)	same Avalonia/.NET versions, net10.0-macos

To Reproduce

Steps to reproduce

1. Create a view containing nothing but a TextBlock and a Button:

   <UserControl xmlns="https://github.com/avaloniaui"
                xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                x:Class="MyApp.Views.MainView">
       <StackPanel Margin="40" Spacing="16">
           <TextBl
   ock Text="Heading" FontSize="24" />
           <Button Content="Test button" />
       </StackPanel>
   </UserControl>
   

2. Deploy to a physical iOS device (iOS 26.6).

3. Enable VoiceOver.

4. Tap the button, or swipe right from the top of the screen.

Expected behavior

Expected

VoiceOver places its cursor on the elements and announces "Heading" and "Test button, button", as it does for the equivalent view on macOS.

Actual

Only the "no element found" tone. No focus rectangle appears, nothing is announced, and double-tap does nothing. Turning VoiceOver off restores normal touch interaction immediately.

Avalonia version

12.1.0

OS

iOS

Additional context

What has been ruled out

This started as an investigation into a production app for blind and visually impaired users, where the same symptom appears on every screen. The following were eliminated one by one:

• Missing or incorrect automation properties. All interactive controls are real Button instances carrying AutomationProperties.Name, set both in XAML and via AutomationProperties.SetName for dynamically built items.
• Custom or non-standard controls. The reduced case above contains only a stock TextBlock and Button.
• LayoutTransformControl. The app wraps its content in one for UI scaling. Removing it entirely changed nothing. (This had seemed a plausible cause, since VoiceOver on iOS hit-tests by screen coordinates rather than walking the tree as it does on macOS.)
• Bundle localization. CFBundleDevelopmentRegion and CFBundleLocalizations were absent and have been added. This fixed a separate issue on macOS, where Dutch text was being read with an English voice, but made no difference to element discovery on iOS.
• Trimming. The failure occurs in Debug builds, where trimming is not applied.
• Navigation and layout infrastructure. Reducing MainView to the two controls shown above — no navigation host, no ContentControl, no insets handling — did not change the behaviour.

macOS comparison

A stock dotnet new avalonia.xplat project, unmodified apart from adding a TextBlock and a Button, was built for macOS and tested with VoiceOver. Both elements are announced correctly. The production app on macOS behaves the same way: tab navigation works and labels are read.

We were unable to build that same template project for iOS to complete the comparison — it failed on codesigning (Disallowed xattr com.apple.FinderInfo) after several attempts on this machine. The iOS evidence above therefore comes from the production app reduced to a minimal view, rather than from a fresh template. Anyone able to build a clean template for iOS should be able to confirm or contradict this in a few minutes, and that would be worth doing before assuming the cause is what it appears to be.

Impact

The application is being built for a library service for blind and visually impaired readers. VoiceOver support is not an enhancement here — it is the only way most of the intended audience can use the app at all. The macOS, Windows (NVDA) and Android builds are all usable; iOS is currently not shippable.

Happy to provide a stripped-down reproduction project, device logs, or to test a patch.

[MrJul]

VoiceOver support was merged very recently.
It's going to be part of the next release.

Don't hesitate to test the nightly builds and report back!

[HenriApperloo]

Thanks for linking this to #18016 — that is clearly the same issue as #20125,
and the merged PR looks like exactly what we need. Apologies for the duplicate;
I searched before filing but did not find the earlier report.

I would like to add a vote for the backport to 12.1.x. We are building a DAISY
audiobook and text reading application for Stichting CBB, the Dutch library
service for blind and visually impaired readers. Every one of our users depends
on a screen reader, so this is not a nice-to-have for us — it is the difference
between shipping on iOS and not shipping at all. Our macOS, Windows (NVDA) and
Android builds are already usable; iOS is the only platform holding us back.

I will test 12.2.999-cibuild0069019-alpha on a physical device this week and
report back here. Happy to help verify a backport on our hardware as well.

[HenriApperloo]

Tested 12.2.999-cibuild0069019-alpha on a physical device (iPhone 17,
iOS 26.6) with our production app. VoiceOver now works: elements are announced
with their AutomationProperties.Name, controls activate, and text input works.
This resolves the problem I reported.

Two things worth noting for the backport discussion:

• We had to clear the NuGet cache and all bin/obj folders when switching to the
  alpha, otherwise the old libAvaloniaNative.dylib stayed in place and the macOS
  build crashed with SIGILL in IAvnPlatformSettings. Presumably an ABI change
  between 12.1.1 and main — probably expected, but it cost us some time.

• We have not yet had a daily screen reader user try it. I can say the tree is
  populated and navigation works; whether it is comfortable to use across a full
  application is something our testers at the library will judge next week.
  Happy to report back on that.

Thanks to @IsaMorphic for the work on this. Adding my vote for the 12.1.x
backport — this is the difference between shipping on iOS and not shipping.