Setting AutomationProperties.Name is a good start. It is not an accessibility strategy.

A cross-platform control has to turn into UI Automation on Windows, NSAccessibility on macOS, ARIA in the browser, UIAccessibility on iOS and AccessibilityNodeInfo on Android, and then survive contact with VoiceOver, TalkBack, NVDA and whatever the user has actually configured. Roles that look equivalent often aren't. Focus moves differently on every one of them. Virtualized controls vanish and come back as something slightly different. Fairly often the screen reader is reading a tree the app developer has never seen.

Drawing on accessibility work in Uno Platform and its Toolkit, and on native-tree inspection in .NET MAUI, I'll walk through cases where the intent made it across and cases where it quietly didn't: a TabBar announced as a generic group, a virtualized item that disappears from the automation tree, a popup with no dismiss action, and a high-contrast theme that updates only part of the page.

Less about which properties exist, more about why setting them correctly still isn't enough. The bar isn't parity between platforms. It's someone getting through your app.

For UI developers who know basic accessibility properties and want to understand the native layer beneath them. Includes screen-reader and automation demonstrations using public Uno Platform and .NET MAUI work. Preferred duration: 60 minutes including Q&A.